Thread (24 messages) 24 messages, 8 authors, 2002-12-28

Re: shared pagetable benchmarking

From: Andrew Morton <hidden>
Date: 2002-12-27 09:59:00

Daniel Phillips wrote:
On Monday 23 December 2002 17:15, Dave McCracken wrote:
quoted
quoted
quoted
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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help