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 - 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:38 EST