All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andi Kleen <ak@suse.de>
Cc: Ray Bryant <raybry@sgi.com>, Andrew Morton <akpm@osdl.org>,
	Ray Bryant <raybry@austin.rr.com>, linux-mm <linux-mm@kvack.org>,
	Jesse Barnes <jbarnes@sgi.com>, Dan Higgins <djh@sgi.com>,
	lse-tech <lse-tech@lists.sourceforge.net>,
	Brent Casavant <bcasavan@sgi.com>,
	Nick Piggin <piggin@cyberone.com.au>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Paul Jackson <pj@sgi.com>, Dave Hansen <haveblue@us.ibm.com>,
	stevel@mwwireless.net
Subject: Re: [PATCH 2.6.9-rc2-mm1 0/2] mm: memory policy for page cache allocation
Date: Tue, 21 Sep 2004 02:33:16 -0700	[thread overview]
Message-ID: <20040921093316.GG9106@holomorphy.com> (raw)
In-Reply-To: <20040921091353.GG8058@wotan.suse.de>

On Mon, Sep 20, 2004 at 08:30:12PM -0500, Ray Bryant wrote:
>> I'm sorry if this is confusing, personal terminology usually gets in the 
>> way.
>> The idea is that just like for the page allocation policy (your current 
>> code), if you wanted, you would have a global, default page cache 
>
On Tue, Sep 21, 2004 at 11:13:54AM +0200, Andi Kleen wrote:
> Having both a per process page cache and a global page cache policy
> would seem like overkill to me.
> And having both doesn't make much sense anyways, because when the 
> system admin wants to change the global policy to free memory
> on nodes he would still need to worry about conflicting per process policies 
> anyways. So as soon as you have process policy you cannot easily
> change global anymore.

Ray, would being able to change the default policy via kernel command-
line options (and perhaps sysctl) suffice? It seems that a global
default and some global state (e.g. per-cpu state) should largely
capture what you're after. If not, could you clarify where it doesn't?

Also, this switch statement stuff is getting a little hairy; maybe
it's time to bring in mempolicy_ops. Or at least trudging through the
switch () statements is turning into a moderate amount of work for me.


-- wli

WARNING: multiple messages have this Message-ID (diff)
From: William Lee Irwin III <wli@holomorphy.com>
To: Andi Kleen <ak@suse.de>
Cc: Ray Bryant <raybry@sgi.com>, Andrew Morton <akpm@osdl.org>,
	Ray Bryant <raybry@austin.rr.com>, linux-mm <linux-mm@kvack.org>,
	Jesse Barnes <jbarnes@sgi.com>, Dan Higgins <djh@sgi.com>,
	lse-tech <lse-tech@lists.sourceforge.net>,
	Brent Casavant <bcasavan@sgi.com>,
	Nick Piggin <piggin@cyberone.com.au>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Paul Jackson <pj@sgi.com>, Dave Hansen <haveblue@us.ibm.com>,
	stevel@mwwireless.net
Subject: Re: [PATCH 2.6.9-rc2-mm1 0/2] mm: memory policy for page cache allocation
Date: Tue, 21 Sep 2004 02:33:16 -0700	[thread overview]
Message-ID: <20040921093316.GG9106@holomorphy.com> (raw)
In-Reply-To: <20040921091353.GG8058@wotan.suse.de>

On Mon, Sep 20, 2004 at 08:30:12PM -0500, Ray Bryant wrote:
>> I'm sorry if this is confusing, personal terminology usually gets in the 
>> way.
>> The idea is that just like for the page allocation policy (your current 
>> code), if you wanted, you would have a global, default page cache 
>
On Tue, Sep 21, 2004 at 11:13:54AM +0200, Andi Kleen wrote:
> Having both a per process page cache and a global page cache policy
> would seem like overkill to me.
> And having both doesn't make much sense anyways, because when the 
> system admin wants to change the global policy to free memory
> on nodes he would still need to worry about conflicting per process policies 
> anyways. So as soon as you have process policy you cannot easily
> change global anymore.

Ray, would being able to change the default policy via kernel command-
line options (and perhaps sysctl) suffice? It seems that a global
default and some global state (e.g. per-cpu state) should largely
capture what you're after. If not, could you clarify where it doesn't?

Also, this switch statement stuff is getting a little hairy; maybe
it's time to bring in mempolicy_ops. Or at least trudging through the
switch () statements is turning into a moderate amount of work for me.


-- wli
--
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>

  reply	other threads:[~2004-09-21  9:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-20 19:00 [PATCH 2.6.9-rc2-mm1 0/2] mm: memory policy for page cache allocation Ray Bryant
2004-09-20 19:00 ` Ray Bryant
2004-09-20 19:00 ` [PATCH 2.6.9-rc2-mm1 1/2] " Ray Bryant
2004-09-20 19:00   ` Ray Bryant
2004-09-20 19:00 ` [PATCH 2.6.9-rc2-mm1 2/2] " Ray Bryant
2004-09-20 19:00   ` Ray Bryant
2004-09-20 20:22 ` [PATCH 2.6.9-rc2-mm1 0/2] " Paul Jackson
2004-09-20 20:22   ` Paul Jackson
2004-09-20 20:55 ` Andi Kleen
2004-09-20 20:55   ` Andi Kleen
2004-09-20 22:13   ` Ray Bryant
2004-09-20 22:13     ` Ray Bryant
2004-09-20 22:37     ` Andi Kleen
2004-09-20 22:37       ` Andi Kleen
2004-09-20 23:16       ` William Lee Irwin III
2004-09-20 23:16         ` William Lee Irwin III
2004-09-21  1:30       ` Ray Bryant
2004-09-21  1:30         ` Ray Bryant
2004-09-21  9:13         ` Andi Kleen
2004-09-21  9:13           ` Andi Kleen
2004-09-21  9:33           ` William Lee Irwin III [this message]
2004-09-21  9:33             ` William Lee Irwin III
2004-09-21 13:10             ` Ray Bryant
2004-09-21 13:10               ` Ray Bryant
2004-09-20 22:38   ` Steve Longerbeam
2004-09-20 23:48   ` Steve Longerbeam
2004-09-23 15:54     ` [PATCH " Ray Bryant
2004-09-23 15:54       ` Ray Bryant
2004-09-23 23:01       ` Steve Longerbeam
2004-09-23 23:01         ` Steve Longerbeam

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=20040921093316.GG9106@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=bcasavan@sgi.com \
    --cc=djh@sgi.com \
    --cc=haveblue@us.ibm.com \
    --cc=jbarnes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=piggin@cyberone.com.au \
    --cc=pj@sgi.com \
    --cc=raybry@austin.rr.com \
    --cc=raybry@sgi.com \
    --cc=stevel@mwwireless.net \
    /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.