Re: shared pagetable benchmarking

[Andrew Morton <akpm@digeo.com>]

Daniel Phillips wrote:
> 
> On Monday 23 December 2002 17:15, Dave McCracken wrote:
> > >> Let's also not lose sight of what I consider the primary goal of shared
> > >> page tables, which is to greatly reduce the page table memory overhead
> > >> of massively shared large regions.
> > >
> > > Well yes.  But this is optimising the (extremely) uncommon case while
> > > penalising the (very) common one.
> >
> > I guess I don't see wasting extra pte pages on duplicated mappings of
> > shared memory as extremely uncommon.  Granted, it's not that significant
> > for small applications, but it can make a machine unusable with some large
> > applications.  I think being able to run applications that couldn't run
> > before to be worth some consideration.
> >
> > I also have a couple of ideas for ways to eliminate the penalty for small
> > tasks.  Would you grant that it's a worthwhile effort if the penalty for
> > small applications was zero?
> 
> Hi Dave, Andrew,

Daniel!

> A feature of my original demonstration patch was that I could enable/disable
> sharing with a per-fork granularity.  This is a good thing.  You can use this
> by detecting the case you can't optimize, i.e., forking from bash, and
> essentially using the old code.  The sawoff for improved efficiency comes in
> somewhere over 4 meg worth of shared memory, which just doesn't happen in
> fork+exec from bash.  Then there is always-unshare situation with the stack,
> which I'm sure you're aware of, where it's never worth doing the share.

Yes, Dave did a prototype of that, and I am sure that it will pull back
the small additional cost of pagetable sharing in those cases.

But that's not the problem.  The problem is that it doesn't *speed up*
that case.  Which appears to be the only thing which interests Linus
in shared pagetables at this time: he "_hate_"s the fact that fork/exec
got slower.

> That said, was not Ingo working on a replacement for fork+exec that doesn't
> do the useless fork?  Would this not make the vast majority of
> impossible-to-optimize cases go away?

That's news to me.

posix_spawn() has been suggested by Ulrich, and he says that things like
bash could easily be converted.

I don't how much it would gain - possibly not a huge amount; the rmap
setup in exec seems to be where the major cost lies.  Plus there's still
exit().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/