Paul Jackson wrote:
1) If your other patch to manipulate sched domains
has code that belongs in kernel/cpuset.c, and
special files that belong in /dev/cpuset, why
shouldn't this one naturally go in the same places?
Because they are cpuset specific. This is not.
Bizarre. That other patch of yours, that had cpu_exclusive cpusets
only at the top level defining sched domain partitions, is cpuset
I'm talking about isolcpus. What do isolcpus have to do with cpusets.c?
You can turn off CONFIG_CPUSETS and still use isolcpusets, can't you?
specific only because you're hijacking the cpu_exclusive flag to add
new semantics to it, and then claiming you're not adding new semantics
to it, and then claiming we should be doing this all implicitly without
additional kernel-user API apparatus, and then claiming that if your
new abuse of cpuset flags intrudes on other usage patterns of cpusets
or if they have need of a particular sched domain partitioning that
they have to explicitly set up top level cpusets to get a desired sched
domain partitioning ...
Stop already ... this is getting insane.
Where are we?
I'll start again...
set_cpus_allowed is a feature of the scheduler that allows you to
restrict one task to a subset of all cpus. Right?
And cpusets uses this interface as the mechanism to implement the
semantics which the user has asked for. Yes?
sched-domains partitioning is a feature of the scheduler that
allows you to restrict zero or more tasks to the partition, and
zero or more tasks to the complement of the partition. OK?
So if you have a particular policy you need to implement, which is
one cpus_exclusive cpuset off the root, covering half the cpus in
the system (as a simple example)... why is it good to implement
that with set_cpus_allowed and bad to implement it with partitions?
Or, another question, how does my patch hijack cpus_allowed? In
what way does it change the semantics of cpus_allowed?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
