> (c) redo the logic around page_convert_anon() and incrementally build
> pte_chains for remap_file_pages().
> The anobjrmap code did exactly this, but it was chaining
> distinct user virtual addresses instead.
> (i) you always have the pte_chain in hand anyway; the core
> is always prepped to handle allocating them now
> (ii) instead of just bailing for file-backed pages in
> page_add_rmap(), pass it enough information to know
> whether the address matches what it should from the
> vma, and start chaining if it doesn't
> (iii) but you say ->mapcount sharing space with the chain is a
> problem? no, it's not; again, take a cue from anobjrmap:
> if a file-backed page needs a pte_chain, shoehorn
> ->mapcount into the first pte_chain block dangling off it
> After all 3 are done, remap_file_pages() integrates smoothly into the VM,
> requires no magical privileges, nothing magical or brutally invasive
> that would scare people just before 2.6.0 is required, and the big
> apps can get their magical lowmem savings by just mlock()'ing _anything_
> they do massive sharing with, regardless of remap_file_pages().
> Does anyone get it _now_?
If you have (anon) object based rmap, I don't see why you want to build
a pte_chain on a per-page basis - keeping this info on a per linear
area seems much more efficient. We still have a reverse mapping for
everything this way.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:17 EST