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

[Paul Jackson <pj@sgi.com>]

Nick wrote:
> You shouldn't need to, assuming cpusets doesn't mess it up.

I'm guessing we're agreeing that the routines update_cpu_domains()
and related code in kernel/cpuset.c are messing things up.

I view that code as a failed intrustion of some sched domain code into
cpusets, and apparently you view that code as a failed attempt to
manage sched domains coming from cpusets.

Oh well ... finger pointing is such fun ;).

(Fortunately I've forgotten who wrote these routines ... best
I don't know.  Whoever you are, don't take it personally.  It
was nice clean code, caught between the rock and the flood.)


> +	non_partitioned = top_cpuset.cpus_allowed;
> +	update_cpu_domains_children(&top_cpuset, &non_partitioned);
> +	partition_sched_domains(&non_partitioned);

So ... instead of throwing the baby out, you want to replace it
with a puppy.  If one attempt to overload cpu_exclusive didn't
work, try another.

I have two problems with this.

1) I haven't found any need for this, past the need to mark some
   CPUs as isolated from the scheduler balancing code, which we
   seem to be agreeing on, more or less, on another patch.

   Please explain why we need this or any such mechanism for user
   space to affect sched domain partitioning.

2) I've had better luck with the cpuset API by adding new flags
   when I needed some additional semantics, rather than overloading
   existing flags.  So once we figure out what's needed and why,
   then odds are I will suggest a new flag, specific to that purpose.

   This new flag might well logically depend on the cpu_exclusive
   setting, if that's useful.  But it would probably be a separate
   flag or setting.

   I dislike providing explicit mechanisms via implicit side affects.

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