Re: What to expect with the 2.6 VM

[William Lee Irwin III <wli@holomorphy.com>]

At some point in the past, I wrote:
>> (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.
>> 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().

On Wed, Jul 02, 2003 at 02:48:14PM -0700, Martin J. Bligh wrote:
> 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.

Eh? This is just suggesting using similar devices as were used in the
anobjrmap patch. I'm not terribly convinced about the remap_file_pages()
extents, since they're only going to be a factor of 8 or so space
reduction.

anobjrmap actually didn't use vma-like devices for anon pages, it merely
chained mm's that could share anon pages (fork()'s between exec()'s)
in a list that could be scanned, tagged anon pages with vaddrs, and
then walks that list of mm's when unmapping or checking referenced bits.


-- wli