From: Daniel Phillips <phillips@arcor.de>
To: Dave McCracken <dmccr@us.ibm.com>, Andrew Morton <akpm@digeo.com>
Cc: linux-mm@kvack.org
Subject: Re: shared pagetable benchmarking
Date: Fri, 27 Dec 2002 10:39:35 +0100 [thread overview]
Message-ID: <E18RqyB-0001ui-00@starship> (raw)
In-Reply-To: <45600000.1040660127@baldur.austin.ibm.com>
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,
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.
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?
Regards,
Daniel
--
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/
next prev parent reply other threads:[~2002-12-27 9:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-20 11:11 Andrew Morton
2002-12-20 11:13 ` William Lee Irwin III
2002-12-20 16:30 ` Dave McCracken
2002-12-20 19:59 ` Andrew Morton
2002-12-23 16:15 ` Dave McCracken
2002-12-23 23:54 ` Andrew Morton
2002-12-27 9:39 ` Daniel Phillips [this message]
2002-12-27 9:58 ` Andrew Morton
2002-12-27 15:59 ` Daniel Phillips
2002-12-27 20:02 ` Linus Torvalds
2002-12-27 20:16 ` Dave McCracken
2002-12-27 20:18 ` Linus Torvalds
2002-12-27 20:45 ` Dave McCracken
2002-12-27 20:50 ` Linus Torvalds
2002-12-27 23:56 ` Daniel Phillips
2002-12-28 0:45 ` Martin J. Bligh
2002-12-28 2:34 ` Andrew Morton
2002-12-28 3:10 ` Linus Torvalds
2002-12-28 6:58 ` Andrew Morton
2002-12-28 7:39 ` Ingo Molnar
2002-12-28 7:47 ` Linus Torvalds
2002-12-28 23:28 ` Andrew Morton
2002-12-28 3:19 ` Martin J. Bligh
2002-12-23 18:19 ` Dave McCracken
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E18RqyB-0001ui-00@starship \
--to=phillips@arcor.de \
--cc=akpm@digeo.com \
--cc=dmccr@us.ibm.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox