Re: [PATCH] Rmap speedup

[Daniel Phillips <phillips@arcor.de>]

On Wednesday 07 August 2002 22:34, Andrew Morton wrote:
> Daniel Phillips wrote:
> > 
> > On Wednesday 07 August 2002 21:40, Andrew Morton wrote:
> > > Daniel Phillips wrote:
> > > > What stands out for me is that rmap is now apparently at parity with
> > > > (virtual scanning) 2.4.19 for a real application, i.e., parallel make.
> > > > I'm sure we'll still see the raw setup/teardown overhead if we make a
> > > > point of going looking for it, but it would be weird if we didn't.
> > > >
> > > > So can we tentatively declare victory of the execution overhead issue?
> > >
> > > err, no.  It's still adding half a millisecond or so to each fork/exec/exit
> > > cycle.  And that is arising from, apparently, an extra two cache misses
> > > per page.  Doubt if we can take this much further.
> > 
> > But that overhead did not show up in the kernel build timings you posted,
> > which do a realistic amount of forking.  So what is the worry, exactly?
> 
> Compilation is compute-intensive, not fork-intensive.  Think shell
> scripts, arch, forking servers, ...

OK, so what is an example of a real application that does tons of forking?
We need to get numbers for that.  We also need to compare such numbers to
the supposed advantage in swapping.

> > > Is it useful to instantiate the swapped-in page into everyone's
> > > pagetables, save some minor faults?
> > 
> > That's what I was thinking, then we just have to figure out how to find
> > all those swapped-out ptes efficiently.
> 
> page->pte?

Problem: we went and gave away the page when we swapped it out, but yes,
we could save the pte chain somewhere and maybe that's a win.  It would
eat memory just when we're trying to get some back, though.

> It may be a net loss for high sharing levels.  Dunno.

High sharing levels are exactly where the swap-in problem is going to
rear its ugly head.

-- 
Daniel