public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: akpm@linux-foundation.org, ak@suse.de, clameter@sgi.com,
	Lee.Schermerhorn@hp.com, linux-kernel@vger.kernel.org
Subject: Re: [patch 3/3] cpusets: add memory_spread_user option
Date: Thu, 25 Oct 2007 23:04:09 -0700	[thread overview]
Message-ID: <20071025230409.81f20ed3.pj@sgi.com> (raw)
In-Reply-To: <alpine.DEB.0.9999.0710251913350.30400@chino.kir.corp.google.com>

Hmmm ... another doubt crosses my mind, something perhaps along the
lines of Christoph's earlier concerns of more interactions between
cpusets and mempolicy.

I'm figuring that when someone looks at the cpuset flag:

	memory_spread_user

they will expect that turning it on will cause user space memory to be
spread over the nodes of the cpuset.  Sure makes sense that it would
mean that.

But, for the most part, it doesn't.  Only tasks that have
previously called set_mempolicy(MPOL_INTERLEAVE), and only
after the 'mems' of the cpuset are subsequently changed,
will have their user memory forced to be spread across the
cpuset as a result of this flag setting.

That's weird.  We really should not surprise users like that.

This is a dangerous situation -- the obvious meaning of a flag
is not what it means.

Any chance, David, that you could have this flag mean:

  	Spread user memory allocations over the cpuset,
	period, anytime it is set, regardless of what
	mempolicy calls the task has made and regardless
	of whether or not or when the cpusets 'mems' were
	last changed.

In your previous reply, you wrote:
> This option gives the most power to applications.

Most power, or excessive confusion?  Straight forward consistency and
simple predictability are far more important in almost all cases.  The
usual exception is when you have a serious use case requiring
something that can only be done in a more obscure fashion.

There is always a price paid for supporting such complexities in an API
however, the price being increased confusion, frustration, errors and
bugs on the part of most users of the API.

... Now most likely you will claim you have such a use case, and when
I ask for it, I will be frustrated at the lack of compelling detail of
what is going on in user space - what sorts of users, apps and systems
involved.  Ok, no biggie.  If this goes down that path, then perhaps
at least I need to reconsider the name:

	memory_spread_user

This is -not- like the other memory spread flags.  It only spreads user
memory across the cpuset if previously, in order, (1) the task did
set_mempolicy(MPOL_INTERLEAVE), then (2) someone modified the cpusets
'mems'.  Perhaps the following ugly name better warns users of such
odd behaviour:

	memory_spread_mpol_interleave

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  reply	other threads:[~2007-10-26  6:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26  2:14 [patch 1/3] cpusets: extract mmarray loading from update_nodemask David Rientjes
2007-10-26  2:14 ` [patch 2/3] mempolicy: mpol_rebind_policy cleanup David Rientjes
2007-10-26  2:14   ` [patch 3/3] cpusets: add memory_spread_user option David Rientjes
2007-10-26  6:04     ` Paul Jackson [this message]
2007-10-26  9:23       ` David Rientjes
2007-10-26  9:56         ` Paul Jackson
2007-10-26 17:18           ` Paul Jackson
2007-10-26 17:39             ` Christoph Lameter
2007-10-26 17:43               ` Paul Jackson
2007-10-26 17:43             ` Lee Schermerhorn
2007-10-26 17:54               ` Paul Jackson
2007-10-26 18:00                 ` Christoph Lameter
2007-10-26 20:39                 ` Lee Schermerhorn
2007-10-26 20:41           ` David Rientjes
2007-10-26  2:46   ` [patch 2/3] mempolicy: mpol_rebind_policy cleanup Paul Jackson

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=20071025230409.81f20ed3.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox