On Friday 02 August 2002 22:20, Andrew Morton wrote:
> Daniel Phillips wrote:
> >
> > This patch eliminates about 35% of the raw rmap setup/teardown overhead by
> > adopting a new locking interface that allows the add_rmaps to be batched
> > in copy_page_range.
>
> Well that's fairly straightforward, thanks. Butt-ugly though ;)
I could try "fast is beautiful" or "beauty is in the eye of the beholder",
but I think I'll stick with "beauty isn't the point just now".
> Don't bother doing teardown yet. I have patches which batch
> all the zap_page_range activity into 16-page chunks, so we
> eventually end up in a single function with 16 virtually-contiguous
> pages to release. Adding the batched locking to that will
> be simple.
Great. Well, both the locking locality of anonymous pages and the dispersion
of mmaped pages could be improved considrably, so maybe I'll play around with
those a little. Taking a wild guess, it might be good for another 5-10%
overhead reduction, and won't impact the basic structure.
> Sigh. I have a test which sends the 2.5.30 VM into a five-minute
> coma
That doesn't sound like a rmap problem per se. Is the test posted?
> and which immediately panics latest -ac with pte_chain oom.
> Remind me again why all this is worth it?
It will be worth it when we finally have a system that swaps well and doesn't
die if you throw a lot of disk IO at it (like BSD). It will be doubly worth
it when active defragmentation happens.
What we will end up with at the end of this cycle will have all the solidity
and flexibility of the BSD VM with little of the complexity. According to me
anyway ;-)
-- Daniel - 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 Aug 07 2002 - 22:00:21 EST