From: Andrew Morton <akpm@osdl.org>
To: Rohit Seth <rohit.seth@intel.com>
Cc: clameter@engr.sgi.com, torvalds@osdl.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: Free pages from local pcp lists under tight memory conditions
Date: Wed, 23 Nov 2005 11:55:45 -0800 [thread overview]
Message-ID: <20051123115545.69087adf.akpm@osdl.org> (raw)
In-Reply-To: <1132775194.25086.54.camel@akash.sc.intel.com>
Rohit Seth <rohit.seth@intel.com> wrote:
>
> On Wed, 2005-11-23 at 11:30 -0800, Christoph Lameter wrote:
> > On Tue, 22 Nov 2005, Rohit Seth wrote:
> >
> > > [PATCH]: This patch free pages (pcp->batch from each list at a time) from
> > > local pcp lists when a higher order allocation request is not able to
> > > get serviced from global free_list.
> >
> > Ummm.. One controversial idea: How about removing the complete pcp
> > subsystem? Last time we disabled pcps we saw that the effect
> > that it had was within noise ratio on AIM7. The lru lock taken without
> > pcp is in the local zone and thus rarely contended.
>
> Oh please stop.
>
> This per_cpu_pagelist is one great logic that has got added in
> allocator. Besides providing pages without the need to acquire the zone
> lock, it is one single main reason the coloring effect is drastically
> reduced in 2.6 (over 2.4) based kernels.
>
hm. Before it was merged in 2.5.x, the feature was very marginal from a
performance POV in my testing on 4-way.
I was able to demonstrate a large (~60%?) speedup in one microbenckmark
which consisted of four processes writing 16k to a file and truncating it
back to zero again. That gain came from the cache warmth effect, which is
the other benefit which these cpu-local pages are supposed to provide.
I don't think Martin was able to demonstrate much benefit from the lock
contention reduction on 16-way NUMAQ either.
So I dithered for months and it was a marginal merge, so it's appropriate
to justify the continued presence of the code.
We didn't measure for any coloring effects though. In fact, I didn't know
that this feature actually provided any benefit in that area.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: Rohit Seth <rohit.seth@intel.com>
Cc: clameter@engr.sgi.com, torvalds@osdl.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: Free pages from local pcp lists under tight memory conditions
Date: Wed, 23 Nov 2005 11:55:45 -0800 [thread overview]
Message-ID: <20051123115545.69087adf.akpm@osdl.org> (raw)
In-Reply-To: <1132775194.25086.54.camel@akash.sc.intel.com>
Rohit Seth <rohit.seth@intel.com> wrote:
>
> On Wed, 2005-11-23 at 11:30 -0800, Christoph Lameter wrote:
> > On Tue, 22 Nov 2005, Rohit Seth wrote:
> >
> > > [PATCH]: This patch free pages (pcp->batch from each list at a time) from
> > > local pcp lists when a higher order allocation request is not able to
> > > get serviced from global free_list.
> >
> > Ummm.. One controversial idea: How about removing the complete pcp
> > subsystem? Last time we disabled pcps we saw that the effect
> > that it had was within noise ratio on AIM7. The lru lock taken without
> > pcp is in the local zone and thus rarely contended.
>
> Oh please stop.
>
> This per_cpu_pagelist is one great logic that has got added in
> allocator. Besides providing pages without the need to acquire the zone
> lock, it is one single main reason the coloring effect is drastically
> reduced in 2.6 (over 2.4) based kernels.
>
hm. Before it was merged in 2.5.x, the feature was very marginal from a
performance POV in my testing on 4-way.
I was able to demonstrate a large (~60%?) speedup in one microbenckmark
which consisted of four processes writing 16k to a file and truncating it
back to zero again. That gain came from the cache warmth effect, which is
the other benefit which these cpu-local pages are supposed to provide.
I don't think Martin was able to demonstrate much benefit from the lock
contention reduction on 16-way NUMAQ either.
So I dithered for months and it was a marginal merge, so it's appropriate
to justify the continued presence of the code.
We didn't measure for any coloring effects though. In fact, I didn't know
that this feature actually provided any benefit in that area.
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-11-23 19:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-23 0:10 [PATCH]: Free pages from local pcp lists under tight memory conditions Rohit Seth
2005-11-23 0:10 ` Rohit Seth
2005-11-23 5:36 ` Andrew Morton
2005-11-23 5:36 ` Andrew Morton
2005-11-23 5:58 ` Andrew Morton
2005-11-23 5:58 ` Andrew Morton
2005-11-23 18:17 ` Rohit Seth
2005-11-23 18:17 ` Rohit Seth
2005-11-23 6:36 ` Christoph Lameter
2005-11-23 6:36 ` Christoph Lameter
2005-11-23 6:42 ` Christoph Lameter
2005-11-23 6:42 ` Christoph Lameter
2005-11-23 16:35 ` Linus Torvalds
2005-11-23 16:35 ` Linus Torvalds
2005-11-23 17:03 ` Christoph Lameter
2005-11-23 17:03 ` Christoph Lameter
2005-11-23 17:54 ` Rohit Seth
2005-11-23 17:54 ` Rohit Seth
2005-11-23 18:06 ` Mel Gorman
2005-11-23 18:06 ` Mel Gorman
2005-11-23 19:41 ` Rohit Seth
2005-11-23 19:41 ` Rohit Seth
2005-11-24 9:25 ` Mel Gorman
2005-11-24 9:25 ` Mel Gorman
2005-11-23 23:26 ` Rohit Seth
2005-11-23 23:26 ` Rohit Seth
2005-11-23 19:30 ` Christoph Lameter
2005-11-23 19:30 ` Christoph Lameter
2005-11-23 19:46 ` Rohit Seth
2005-11-23 19:46 ` Rohit Seth
2005-11-23 19:55 ` Andrew Morton [this message]
2005-11-23 19:55 ` Andrew Morton
2005-11-23 21:00 ` Rohit Seth
2005-11-23 21:00 ` Rohit Seth
2005-11-23 21:25 ` Christoph Lameter
2005-11-23 21:25 ` Christoph Lameter
2005-11-23 22:29 ` Rohit Seth
2005-11-23 22:29 ` Rohit Seth
2005-11-23 21:26 ` Andrew Morton
2005-11-23 21:26 ` Andrew Morton
2005-11-23 21:40 ` Rohit Seth
2005-11-23 21:40 ` Rohit Seth
2005-11-24 3:02 ` Paul Jackson
2005-11-24 3:02 ` Paul Jackson
2005-11-29 23:18 ` Rohit Seth
2005-11-29 23:18 ` Rohit Seth
2005-12-01 14:44 ` Paul Jackson
2005-12-01 14:44 ` Paul Jackson
2005-12-02 0:32 ` Nick Piggin
2005-12-02 0:32 ` Nick Piggin
2005-11-23 22:01 ` Christoph Lameter
2005-11-23 22:01 ` Christoph Lameter
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=20051123115545.69087adf.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rohit.seth@intel.com \
--cc=torvalds@osdl.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.