>> >> 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 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/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:54 EST