From: Jack Steiner <steiner@sgi.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@osdl.org, hugh@veritas.com, linux-mm@kvack.org,
linux-ia64@vger.kernel.org
Subject: Re: per_cpu_pagesets degrades MPI performance
Date: Thu, 07 Apr 2005 18:52:27 +0000 [thread overview]
Message-ID: <20050407185226.GA23873@sgi.com> (raw)
In-Reply-To: <4251DE87.10002@yahoo.com.au>
On Tue, Apr 05, 2005 at 10:40:39AM +1000, Nick Piggin wrote:
> Jack Steiner wrote:
>
> [snip nice detective work]
>
> >Has anyone else seen this problem? I am considering adding
> >a config option to allow a site to control the batch size
> >used for per_cpu_pagesets. Are there other ideas that should
> >be pursued?
> >
>
> What about using a non power of 2 for the batch? Like 5.
> If that helps, then we can make a patch to clamp it to a
> good value. At a guess I'd say a power of 2 +/- 1 might be
> the way to go.
>
> Nick
>
> --
> SUSE Labs, Novell Inc.
Good idea. For the specific benchmark that I was running, batch sizes
of 0 (pcp disabled), 1, 3, 5, 7, 9, 10, 11, 13 & 15 all produced good results.
Batch sizes of 2, 4 and 8 produced horrible results.
Surprisingly 7 was not quite as good as the other good values but I attribute that
to an anomaly of the reference pattern of the specific benchmark.
Even more suprising (again an anomaly I think) was that a size of 13 ran
10% faster than any of the other sizes. I reproduced this data point several
times - it is real.
Our next step to to run the full benchmark suite. That should happen
within 2 weeks.
Tentatively, I'm planning to post a patch to change the batch size to
2**n-1 but I'll wait for the results of the full benchmark.
I also want to finish understanding the issue of excessive memory
being trapped in the per_cpu lists.
--
Thanks
Jack Steiner (steiner@sgi.com) 651-683-5302
Principal Engineer SGI - Silicon Graphics, Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Jack Steiner <steiner@sgi.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@osdl.org, hugh@veritas.com, linux-mm@kvack.org,
linux-ia64@vger.kernel.org
Subject: Re: per_cpu_pagesets degrades MPI performance
Date: Thu, 7 Apr 2005 13:52:27 -0500 [thread overview]
Message-ID: <20050407185226.GA23873@sgi.com> (raw)
In-Reply-To: <4251DE87.10002@yahoo.com.au>
On Tue, Apr 05, 2005 at 10:40:39AM +1000, Nick Piggin wrote:
> Jack Steiner wrote:
>
> [snip nice detective work]
>
> >Has anyone else seen this problem? I am considering adding
> >a config option to allow a site to control the batch size
> >used for per_cpu_pagesets. Are there other ideas that should
> >be pursued?
> >
>
> What about using a non power of 2 for the batch? Like 5.
> If that helps, then we can make a patch to clamp it to a
> good value. At a guess I'd say a power of 2 +/- 1 might be
> the way to go.
>
> Nick
>
> --
> SUSE Labs, Novell Inc.
Good idea. For the specific benchmark that I was running, batch sizes
of 0 (pcp disabled), 1, 3, 5, 7, 9, 10, 11, 13 & 15 all produced good results.
Batch sizes of 2, 4 and 8 produced horrible results.
Surprisingly 7 was not quite as good as the other good values but I attribute that
to an anomaly of the reference pattern of the specific benchmark.
Even more suprising (again an anomaly I think) was that a size of 13 ran
10% faster than any of the other sizes. I reproduced this data point several
times - it is real.
Our next step to to run the full benchmark suite. That should happen
within 2 weeks.
Tentatively, I'm planning to post a patch to change the batch size to
2**n-1 but I'll wait for the results of the full benchmark.
I also want to finish understanding the issue of excessive memory
being trapped in the per_cpu lists.
--
Thanks
Jack Steiner (steiner@sgi.com) 651-683-5302
Principal Engineer SGI - Silicon Graphics, Inc.
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-04-07 18:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-04 19:28 per_cpu_pagesets degrades MPI performance Jack Steiner
2005-04-04 19:28 ` Jack Steiner
2005-04-05 0:40 ` Nick Piggin
2005-04-05 0:40 ` Nick Piggin
2005-04-05 3:02 ` Jack Steiner
2005-04-05 3:02 ` Jack Steiner
2005-04-07 18:52 ` Jack Steiner [this message]
2005-04-07 18:52 ` Jack Steiner
2005-04-08 0:41 ` Nick Piggin
2005-04-08 0:41 ` Nick Piggin
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=20050407185226.GA23873@sgi.com \
--to=steiner@sgi.com \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/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.