Re: [PATCH] Rmap speedup

[Daniel Phillips]

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