Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP



> The current xip stack relies on having struct page behind the memory
> segment. This causes few impact on memory management, but occupies some
> more memory. The cramfs patch chose to modify copy on write in order to
> deal with vmas that don't have struct page behind.
> So far, Hugh and Linus have shown strong opposition against copy on
> write with no struct page behind. If this implementation is acceptable
> to the them, it seems preferable to me over wasting memory. The xip
> stack should be modified to use this vma flag in that case.

I would rather not :P

We can copy on write without a struct page behind the source today, no?

The existing COW techniques fail on some corner cases. I'm not up to
speed on the vm code. I'll try to look into this a little more but it
might be useful if I knew what questions I need to answer so you vm
experts can understand the problem.

Let me give one example. If you try to debug an XIP application
without this patch, bad things happen. XIP in this sense is synomous
with executing directly out of Flash and you can't just change the
physical memory to redirect it to the debugger so easily in Flash.
Now I don't know exactly why yet some, but not all applications,
trigger this added vm hack. I'm not sure exactly why it would get
triggered under normal circumstances. Why would a read-only map get
written to?

What is insufficient for the XIP code with the current COW?

So I think the problem may have something to do with the nature of the
memory in question. We are using Flash that is ioremap()'ed to a
usable virtual address. And yet we go on to try to use it as if it
were plain old system memory, like any RAM page. We need it to be
presented as any other memory page only physically read-only.
ioremap() seems to be a hacky way of accomplishing that, but I can't
think of better way. In ARM we even had to invent ioremap_cached() to
improve performance. Thoughts?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: What File System supports Application XIP
    ... > You won't gain at runtime by using XIP though. ... I thought that when you XIPed from flash, ... directly back to the flash memory address. ... There shouldn't be a RAM ...
    (Linux-Kernel)
  • Re: WindowCE 5.0 + XIP Chain question!
    ... use XIP Chain. ... (NAND Flash, CF and etc), the bootloader will need to load the image into ... memory technology and the bootloader will need to load the whole bunch thing ... the new MDD/PDD dose not work well with bootpart.lib and BinFS; ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
    ... This causes few impact on memory management, ... The cramfs patch chose to modify copy on write in order to ... > deal with vmas that don't have struct page behind. ... physical memory to redirect it to the debugger so easily in Flash. ...
    (Linux-Kernel)
  • Re: XU1541 and more USB stuff
    ... memory. ... coming along nicely this week (FAT12/16/32/LFN support working for read ... for significantly more buffering reducing the overhead of the USB ... lots of flash and ram. ...
    (comp.sys.cbm)
  • Re: making a removable SSD drive nonremovable
    ... Using a FLASH based memory card in the way you suggest is a very bad idea. ... Putting in a FLASH based memory will make Windows take a very significant performance hit. ... Are you certain that it's not battery backed RAM? ...
    (microsoft.public.windowsxp.hardware)

Loading