Messages in this thread | | | Date | Sat, 02 Jun 2007 18:42:23 +1000 | From | Nick Piggin <> | Subject | Re: [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/
| |