linux-kernel - Re: [patch 3/3] cpusets: add memory_spread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071025230409.81f20ed3.pj@sgi.com>
Date:	Thu, 25 Oct 2007 23:04:09 -0700
From:	Paul Jackson <pj@....com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	akpm@...ux-foundation.org, ak@...e.de, clameter@....com,
	Lee.Schermerhorn@...com, linux-kernel@...r.kernel.org
Subject: Re: [patch 3/3] cpusets: add memory_spread_user option

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@....com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/