Re: [PATCH 2.5.43-mm2] New shared page table patch

["Martin J. Bligh" <mbligh@aracnet.com>]

>> >> For reference, one of the tests was TPC-H.  My code reduced the number of
>> >> allocated pte_chains from 5 million to 50 thousand.
>> > 
>> > Don't tease, what did that do for performance? I see that someone has
>> > already posted a possible problem, and the code would pass for complex for
>> > most people, so is the gain worth the pain?
>> 
>> In many cases, this will stop the box from falling over flat on it's 
>> face due to ZONE_NORMAL exhaustion (from pte-chains), or even total
>> RAM exhaustion (from PTEs). Thus the performance gain is infinite ;-)
> 
> So why has no one written a pte_chain reaper?  It is perfectly sane
> to allocate a swap entry and move an entire pte_chain to the swap
> cache.  

I think the underlying subsystem does not easily allow for dynamic regeneration, so it's non-trivial. wli was looking at doing pagetable reclaim at some point, IIRC.

IMHO, it's better not to fill memory with crap in the first place than
to invent complex methods of managing and shrinking it afterwards. You
only get into pathalogical conditions under sharing situation, else 
it's limited to about 1% of RAM (bad, but manageable) ... thus providing
this sort of sharing nixes the worst of it. Better cache warmth on 
switches (for TLB misses), faster fork+exec, etc. are nice side-effects.

The ultimate solution is per-object reverse mappings, rather than per
page, but that's a 2.7 thingy now.

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/