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) >> PAGE_SHIFT)

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?

so long,
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at