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

[Nick Piggin <nickpiggin@yahoo.com.au>]

Jared Hulbert wrote:
>> > 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.

Previously I believe we couldn't do COW without a struct page for the
source memory, nor could we COW with a source that is not readable
from the kernel virtual mapping.

Now we can do both. cow_user_page in mm/memory.c does a copy_from_user
if there is no source page, so it uses the user mappings and does not
require a struct page.

The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).

> 
> 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?
> 


-- 
SUSE Labs, Novell Inc.