Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
From: Carsten Otte
Date: Fri Jun 15 2007 - 09:54:17 EST
Nick Piggin wrote:
Carsten Otte 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?
What is insufficient for the XIP code with the current COW?
I've looked at the -mm version of mm/memory.c today, with intend to
try out VM_PFNMAP for our xip mappings and replace nopage() with fault().
The thing is, I believe it does'nt work for us:
* The way we recognize those mappings is through the rules set up
* by "remap_pfn_range()": the vma will have the VM_PFNMAP bit set,
* and the vm_pgoff will point to the first PFN mapped: thus every
* page that is a raw mapping will always honor the rule
* pfn_of_page == vma->vm_pgoff + ((addr - vma->vm_start) >>
This is, as far as I can tell, not true for our xip mappings. Ext2 may
spread the physical pages behind a given file all over its media. That
means, that the pfns of the pages that form a vma may be more or less
random rather than contiguous. The common memory management code
cannot tell whether or not a given page has been COW'ed.
Did I miss something?
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/