Fwd: [patch 00/14] remap_file_pages protection support

[Blaisorblade <blaisorblade@yahoo.it>]

I'm forwarding to you all the introductory e-mail, while sending the patches 
themselves only to linux-kernel (and Andrew Morton for inclusion in -mm).

Unlike last time (which was last summer), I've been able to work on the 
patches only during spare time; however, I think the work should be good 
anyway.

I've incorporated all suggestions from last review round, and left out (at 
least for now) some patches that aren't needed for base functionality; I'll 
reintroduce them after this chunk is in.

I haven't, instead, yet coded what is useful for general userspace usage; that 
will happen later.

Thanks for the attention.

----------  Forwarded Message  ----------

Again (about 8 month since last time, I have much less time during my academic
year), I'm sending for review (and for possible inclusion into -mm) protection
support for remap_file_pages, i.e. setting per-pte protections (beyond file
offset) through this syscall.

== How it works ==

Protections are set in the page tables when the
page is loaded, are saved into the PTE when the page is swapped out and 
restored
when the page is faulted back in.

Additionally, we modify the fault handler since the VMA protections aren't 
valid
for PTE with modified protections.

Finally, we must also provide, for each arch, macros to store also the
protections into the PTE; to make the kernel compile for any arch, I've added
since last time dummy default macros to keep the same functionality.

== What is this for ==

The first idea is to use this for UML - it must create a lot of single page
mappings, and managing them through separate VMAs is slow.

Additional note: this idea, with some further refinements (which I'll code 
after
this chunk is accepted), will allow to reduce the number of used VMAs for most
userspace programs - in particular, it will allow to avoid creating one VMA 
for
one guard pages (which has PROT_NONE) - forcing PROT_NONE on that page will be
enough.

This will be useful since the VMA lookup at fault time can be a bottleneck for
some programs (I've received a report about this from Ulrich Drepper and I've
been told that also Val Henson from Intel is interested about this). I guess
that since we use RB-trees, the slowness is also due to the poor cache 
locality
of RB-trees (since RB nodes are within VMAs but aren't accessed together with
their content), compared for instance with radix trees where the lookup has 
high
cache locality (but they have however space usage problems, possibly bigger, 
on
64-bit machines).

== Notes ==

Implementations are provided for i386, x86_64 and UML, and for some other 
archs
I have patches I will send, based on the ones which were in -mm when Ingo sent
the first version of this work.

You shouldn't worry for the number of patches, most of them are very little.
I've last tested them in UML against 2.6.16-rc3, but I've seen no big changes 
in
the VM.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive 
http://it.messenger.yahoo.com
-
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/