linux-kernel - Re: [RFC] cpuset: remove sched domain hooks from cpusets

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: <20061022213052.A2526@unix-os.sc.intel.com>
Date:	Sun, 22 Oct 2006 21:31:05 -0700
From:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
To:	Paul Jackson <pj@....com>
Cc:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>, dino@...ibm.com,
	nickpiggin@...oo.com.au, mbligh@...gle.com, akpm@...l.org,
	menage@...gle.com, Simon.Derr@...l.net,
	linux-kernel@...r.kernel.org, rohitseth@...gle.com, holt@....com,
	dipankar@...ibm.com, clameter@....com
Subject: Re: [RFC] cpuset: remove sched domain hooks from cpusets

On Fri, Oct 20, 2006 at 10:37:38PM -0700, Paul Jackson wrote:
> > And whenever a child cpuset sets this use_cpus_exclusive flag, remove
> > those set of child cpuset cpus from parent cpuset and also from the
> > tasks which were running in the parent cpuset. We can probably  allow this
> > to happen as long as parent cpuset has atleast one cpu.
> 
> Why are you seeking out obfuscated means and gratuitous entanglements
> with cpuset semantics, in order to accomplish a straight forward end -
> defining the sched domain partitioning?
> 
> If we are going to add or modify the meaning of per-cpuset flags in
> order to determine sched domain partitioning, then we should do so in
> the most straight forward way possible, which by all accounts seems to
> be adding a 'sched_domain' flag to each cpuset, indicating whether it
> delineates a sched domain partition.  The kernel would enforce a rule
> that the CPUs in the cpusets so marked could not overlap.  The kernel
> in return would promise not to split the CPUs in any cpuset so marked
> into more than one sched domain partition, with the consequence that
> the kernel would be able to load balance across all the CPUs contained
> within any such partition.
> 
> Why do something less straightforward than that?

Ok. I went to implementation details(and ended up less straight forward..) but
my main intention was to say that we need to retain some sort of hierarchical 
shape too, while creating these domain partitions.

Like for example, a big system can be divided into different groups of
cpus for each department in an organisation. And internally based
on the needs, each department can divide its pool of cpus into sub groups
and allocates to much smaller group. And based on the sub group creation/
deletion, cpus will move from department to subgroups and viceversa.

users probably want both flat and hierarchical partitions. And in this
partition mechanism, we should never allow cpus being present in more than one
partition.

thanks,
suresh
-
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/