lkml.org 
[lkml]   [2006]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] cpuset: remove sched domain hooks from cpusets
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/

\
 
 \ /
  Last update: 2006-10-19 21:07    [W:1.866 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site