linux-kernel - Re: [PATCH] cpusets: Make cpus_allowed and mems

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: <20141008101828.GG10832@worktop.programming.kicks-ass.net>
Date:	Wed, 8 Oct 2014 12:18:28 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
Cc:	svaidy@...ux.vnet.ibm.com, rjw@...ysocki.net, lizefan@...wei.com,
	anton@...ba.org, tj@...nel.org, paulmck@...ux.vnet.ibm.com,
	mingo@...nel.org, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks
 hotplug invariant

On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:

> > I still completely hate all that.. It basically makes cpusets useless,
> > they no longer guarantee anything, it makes then an optional placement
> > hint instead.
> 
> Why do you say they don't guarantee anything? We ensure that we always
> run on the cpus in our cpuset which are online. We do not run in any
> arbitrary cpuset. We also do not wait unreasonably on an offline cpu to
> come back. What we are doing is ensuring that if the resources that we
> began with are available we use them. Why is this not a logical thing to
> expect?

Because if you randomly hotplug cpus your tasks can randomly flip
between sets.

Therefore there is no strict containment and no guarantees.

> > You also break long standing behaviour.
> 
> Which is? As I understand cpusets are meant to ensure a dedicated set of
> resources to some tasks. We cannot scheduler the tasks anywhere outside
> this set as long as they are available. And when they are not, currently
> we move them to their parents,

No currently we hard break affinity and never look back. That move to
parent and back crap is all new fangled stuff, and broken because of the
above argument.

> but you had also suggested killing the
> task. Maybe this can be debated. But what behavior are we changing by
> ensuring that we retain our original configuration at all times?

See above, by pretending hotplug is a sane operation you loose all
guarantees.

> > Also, power is insane if it needs/uses hotplug for operational crap
> > like that.
> 
> SMT 8 on Power8 can help/hinder workloads. Hence we dynamically switch
> the modes at runtime.

That's just a horrible piece of crap hack and you deserve any and all
pain you get from doing it.

Randomly removing/adding cpus like that is horrible and makes a mockery
of all the affinity interfaces we have.
--
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/