Are you saying that you wished that cpusets was not implemented using
cpus_allowed, but -instead- implemented using sched domain partitioning?
Well, as you likely can guess by now, that's unlikely.
Cpusets provides hierarchically nested sets of CPU and Memory Nodes,
especially useful for managing nested allocation of processor and
memory resources on large systems. The essential mechanism at the core
of cpusets is manipulating the cpus_allowed and mems_allowed masks in
Cpusets have also been dabbling in the business of driving the sched
domain partitioning, but I am getting more inclined as time goes on to
think that was a mistake.
What are you asking for again? ;).
Are you asking for a decent interface to sched domain partitioning?
Perhaps cpusets are not the best way to get that.
I hear tell from my colleague Christoph Lameter that he is considering
trying to make some improvements, that would benefit us all, to the
sched domain partitioning code - smaller, faster, simpler, better and
all that good stuff. Perhaps you guys at Google should join in that
effort, and see to it that your needs are met as well. I would
recommend providing whatever kernel-user API's you need for this, if
any, separately from cpusets.
So far, the requirements that I am aware of on such an effort:
1) Somehow support isolated CPUs (no load balancing to or from them).
For example, at least one real-time project needs these.
2) Whatever you were talking about above that Google is planning, some
sort of partitioning.
3) Somehow, whether by magic or by implicit or explicit partitioning
of the systems CPUs, ensure that its load balancing scales to cover
my employers (SGI) big CPU count systems.
4) Hopefully smaller, less #ifdef'y and easier to understand than the
5) Avoid poor fit interactions with cpusets, which have a different
shape (naturally hierarchical), internal mechanism (allowed bitmasks
rather than scheduler balancing domains), scope (combined processor
plus memory) and natural API style (a full fledged file system to
name these sets, rather than a few bitmasks and flags.)
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson < XXXX@XXXXX.COM > 1.925.600.0401
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/