From: Rohit Seth <rohit.seth@intel.com>
To: Andrew Morton <akpm@osdl.org>
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 13:40:48 -0800 [thread overview]
Message-ID: <1132782048.25086.76.camel@akash.sc.intel.com> (raw)
In-Reply-To: <20051123132647.257710b9.akpm@osdl.org>
On Wed, 2005-11-23 at 13:26 -0800, Andrew Morton wrote:
> Rohit Seth <rohit.seth@intel.com> wrote:
> >
> > > 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.
> > >
> >
> > May be the limits on the number of pages hanging on the per_cpu_pagelist
> > was (or even now is) too small (for them to give any meaningful gain).
> > May be we should have more physical contiguity in each of these pcps to
> > give better cache spread.
>
> Could be. The initial settings were pretty arbitrary - I assumed that
> someone would get in and tune them up, but nothing much happened. Perhaps
> we should expose the thresholds in /proc/sys/vm so they're easier to play
> with.
Most certainly. If I had a patch ready...I would have given you one
right away :-) Though I will work on it...
It surely is unfortunate that we have not digged deeper into this area
(in terms of optimizations)....
-rohit
WARNING: multiple messages have this Message-ID (diff)
From: Rohit Seth <rohit.seth@intel.com>
To: Andrew Morton <akpm@osdl.org>
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 13:40:48 -0800 [thread overview]
Message-ID: <1132782048.25086.76.camel@akash.sc.intel.com> (raw)
In-Reply-To: <20051123132647.257710b9.akpm@osdl.org>
On Wed, 2005-11-23 at 13:26 -0800, Andrew Morton wrote:
> Rohit Seth <rohit.seth@intel.com> wrote:
> >
> > > 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.
> > >
> >
> > May be the limits on the number of pages hanging on the per_cpu_pagelist
> > was (or even now is) too small (for them to give any meaningful gain).
> > May be we should have more physical contiguity in each of these pcps to
> > give better cache spread.
>
> Could be. The initial settings were pretty arbitrary - I assumed that
> someone would get in and tune them up, but nothing much happened. Perhaps
> we should expose the thresholds in /proc/sys/vm so they're easier to play
> with.
Most certainly. If I had a patch ready...I would have given you one
right away :-) Though I will work on it...
It surely is unfortunate that we have not digged deeper into this area
(in terms of optimizations)....
-rohit
--
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 21:34 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
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 [this message]
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=1132782048.25086.76.camel@akash.sc.intel.com \
--to=rohit.seth@intel.com \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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.