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

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

>> >> 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. 
> 
> We swap pages out all of the time in 2.4.x, and that is all I was suggesting 
> swap out some but not all of the pages, on a very long pte_chain.  And swapping
> out a page is not terribly complex, unless something very drastic has changed.

Right, it's swapping out the controlling structures without swapping
out the pages themselves that's harder.
 
>> 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.
> 
> I will agree with that if everything works so the sharing happens,
> this is a nice feature.

I think it will for most of the situations we run aground with now
(normally 5000 oracle tasks sharing a 2Gb shared segment, or some
such monster).
 
>> The ultimate solution is per-object reverse mappings, rather than per
>> page, but that's a 2.7 thingy now.
> ???
> 
> Last I checked we already had those in 2.4.x, and still in 2.5.x.  The
> list of place the address space is mapped.

It's more complicated than that ... I'll let Rik or one of the K42
guys who understand it better than I do explain it (yeah, I'm wimping
out on you ;-))

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/