All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Andrew Morton <akpm@osdl.org>, James Cloos <cloos@jhcloos.com>,
	linux-kernel@vger.kernel.org
Subject: Re: MAP_SHARED bizarrely slow
Date: Thu, 28 Oct 2004 11:16:18 +1000	[thread overview]
Message-ID: <20041028011618.GB2216@zax> (raw)
In-Reply-To: <41800B12.5020405@tmr.com>

On Wed, Oct 27, 2004 at 04:54:42PM -0400, Bill Davidsen wrote:
> Andrew Morton wrote:
> >James Cloos <cloos@jhcloos.com> wrote:
> >
> >>>>>>>"David" == David Gibson <david@gibson.dropbear.id.au> writes:
> >>
> >>David> http://www.ozlabs.org/people/dgibson/maptest.tar.gz
> >>
> >>David> On a number of machines I've tested - both ppc64 and x86 - the
> >>David> SHARED version is consistently and significantly (50-100%)
> >>David> slower than the PRIVATE version.
> >>
> >>Just gave it a test on my laptop and server.  Both are p3.  The
> >>laptop is under heavier mem pressure; the server has just under
> >>a gig with most free/cache/buff.  Laptop is still running 2.6.7
> >>whereas the server is bk as of 2004-10-24.
> >>
> >>Buth took about 11 seconds for the private and around 30 seconds
> >>for the shared tests.
> >>
> >
> >
> >I get the exact opposite, on a P4:
> >
> >vmm:/home/akpm/maptest> time ./mm-sharemmap 
> >./mm-sharemmap  10.81s user 0.05s system 100% cpu 10.855 total
> >vmm:/home/akpm/maptest> time ./mm-sharemmap
> >./mm-sharemmap  11.04s user 0.05s system 100% cpu 11.086 total
> >vmm:/home/akpm/maptest> time ./mm-privmmap 
> >./mm-privmmap  26.91s user 0.02s system 100% cpu 26.903 total
> >vmm:/home/akpm/maptest> time ./mm-privmmap
> >./mm-privmmap  26.89s user 0.02s system 100% cpu 26.894 total
> >vmm:/home/akpm/maptest> uname -a
> >Linux vmm 2.6.10-rc1-mm1 #14 SMP Tue Oct 26 23:23:23 PDT 2004 i686 i686 
> >i386 GNU/Linux
> >
> >It's all user time so I can think of no reason apart from physical page
> >allocation order causing additional TLB reloads in one case.  One is using
> >anonymous pages and the other is using shmem-backed pages, although I can't
> >think why that would make a difference.
> 
> I think the cause was covered in another post, I'm surprised that the 
> page overhead is reported as user time. It would have been a good hint 
> if the big jump were in system time.

The cause isn't page overhead.  The problem is that the SHARED version
actually uses a whole lot more real memory, so cache performance is
much worse.  So the time really is in userland.

-- 
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

  reply	other threads:[~2004-10-28  1:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-27  6:45 MAP_SHARED bizarrely slow David Gibson
2004-10-27  7:23 ` James Cloos
2004-10-27  7:59   ` David Gibson
2004-10-28  4:38     ` Ian Wienand
2004-10-27  8:06   ` Andrew Morton
2004-10-27  8:20     ` David Gibson
2004-10-27  8:30     ` James Cloos
2004-10-27 20:54     ` Bill Davidsen
2004-10-28  1:16       ` David Gibson [this message]
2004-10-28  5:54     ` dean gaudet

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=20041028011618.GB2216@zax \
    --to=david@gibson.dropbear.id.au \
    --cc=akpm@osdl.org \
    --cc=cloos@jhcloos.com \
    --cc=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.