lkml.org 
[lkml]   [2007]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-02 10:45    [W:0.102 / U:2.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site