Dinakar, replying to pj:
> > I don't understand why what's there now isn't sufficient. I don't see
> > that this patch provides any capability that you can't get just by
> > properly placing tasks in cpusets that have the desired cpus and nodes.
> > This patch leaves the per-cpu kernel threads with no cpuset that allows
> > what they need, and it complicates the semantics of things, in ways that
> > I still don't entirely understand.
>
> You are forgetting the fact that the scheduler is still load balancing
> across all CPUs and tries to pull tasks only to find that the task's
> cpus_allowed mask prevents it from being moved
Well, I haven't forgotten, but I am having a difficult time figuring out
what your real (most likely just one or two) essential requirements are.
A few days ago, you provided a six step list, under the introduction:
> Ok, Let me begin at the beginning and attempt to define what I am
> doing here
I suspect those six steps were not really your essential requirements,
but one possible procedure that accomplishes them.
So far I am guessing that your requirement(s) are one or both of the
following two items:
(1) avoid having the scheduler wasting too much time trying to
load balance tasks that only turn out to be not allowed on
the cpus the scheduler is considering, and/or
(2) provide improved administrative control of a system by being
able to construct a cpuset that is guaranteed to have no
overlap of allowed cpus with its parent or any other cpuset
not descendent from it.
If (1) is one of your essential requirements, then I have described a
couple of implementations that mark some existing cpusets to form a
partition (in the mathematical sense of a disjoint covering of subsets)
of the system to define isolated scheduler domains. I did this without
adding any additional bitmasks to each cpuset.
If (2) is one of your essential requirements, then I believe this can be
done with the current cpuset kernel code, entirely with additional user
level code.
> I am working on a minimalistic design right now and will get back in
> a day or two
Good.
Hopefully, you will also be able to get through my thick head what you
essential requirement(s) is or are.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373, 1.925.600.0401
-
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]
