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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
