Re: exclusive cpusets broken with cpu hotplug

[Paul Jackson]

> I don't know if you want customers do know what domains they have. I think
> you should avoid having explicit control over sched-domains in your cpusets
> completely, and just have the cpusets create partitioned domains whenever
> it can.

We have a choice to make.  I am increasingly convinced that the
current mechanism linking cpusets with sched domains is busted,
allowing people to easily and unspectingly set up broken sched domain
configs, without even being able to see what they are doing.
Certainly that linkage has been confusing to some of us who are
not kernel/sched.c experts.  Certainly users on production systems
cannot see what sched domains they have ended up with.

We should either make this linkage explicit and understandable, giving
users direct means to construct sched domains and probe what they have
done, or we should remove this linkage.

My patch to add sched_domain flags to cpusets was an attempt to
make this control explicit.

I am now 90% convinced that this is the wrong direction, and that
the entire chunk of code linking cpu_exclusive cpusets to sched
domains should be nuked.

The one thing I found so far today that people actually needed from
this was that my real time people needed to be able to something like
marking a cpu isolated.  So I think we should have runtime support for
manipulating the cpu_isolated_map.

I will be sending in a pair of patches shortly to:
 1) nuke the cpu_exclusive - sched_domain linkage, and
 2) support runtime marking of isolated cpus.

Does that sound better to you?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@xxxxxxx> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/