On Mon, 2015-03-02 at 09:35 -0500, Rik van Riel wrote: > On 03/02/2015 07:44 AM, Mike Galbraith wrote: > > On Mon, 2015-03-02 at 10:09 +0100, Peter Zijlstra wrote: > >> On Thu, Feb 26, 2015 at 12:12:31PM -0500, Rik van Riel wrote: > >>> Subject: cpusets,isolcpus: add file to show isolated cpus in cpuset > >>> > >>> The previous patch makes it so the code skips over isolcpus when > >>> building scheduler load balancing domains. This makes it hard to > >>> see for a user which of the CPUs in a cpuset are participating in > >>> load balancing, and which ones are isolated cpus. > >>> > >>> Add a cpuset.isolcpus file with info on which cpus in a cpuset are > >>> isolated CPUs. > >>> > >>> This file is read-only for now. In the future we could extend things > >>> so isolcpus can be changed at run time, for the root (system wide) > >>> cpuset only. > >>> > >>> Acked-by: David Rientjes <rientjes@xxxxxxxxxx> > >>> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > >>> Cc: Clark Williams <williams@xxxxxxxxxx> > >>> Cc: Li Zefan <lizefan@xxxxxxxxxx> > >>> Cc: Ingo Molnar <mingo@xxxxxxxxxx> > >>> Cc: Luiz Capitulino <lcapitulino@xxxxxxxxxx> > >>> Cc: David Rientjes <rientjes@xxxxxxxxxx> > >>> Cc: Mike Galbraith <umgwanakikbuti@xxxxxxxxx> > >>> Cc: cgroups@xxxxxxxxxxxxxxx > >>> Signed-off-by: Rik van Riel <riel@xxxxxxxxxx> > >> > >> So let me start off by saying I hate isolcpus ;-) > >> > >> Let me further state that I had hopes we could extend cpusets to > >> natively provide the functionality isolcpus has, and kill isolcpus. > > > > +1 > > > > That's where nohz_full goop belongs too. > > Except nohz_full and isolcpus are very much global attributes of > each CPU, so I am not sure whether it would make sense to allow > configuration of this attribute anywhere other than the root > cpuset. They're attributes of exclusive sets, which excludes the root set. It'd be kinda hard to have the root set be both ticked and tickless :) -Mike -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html