Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Paul Jackson <pj@sgi.com>]

Matthew wrote:
> I should have been more clear that CKRM and CPUSETs (seem) to 
> be unreconcilable.  Sched_domains and CPUSETs (seem) to have some potential 
> functionality overlap that leads me to (still) believe there is hope to 
> integrate these two systems.

Aha - now we're getting somewhere.

I was under the illusion these last four months that you were going to
serve as priest at the shotgun wedding that Andrew had requested be
arranged between cpusets and CKRM.  All this time, you were hoping to
get cpusets hooked up with sched domains.

My daughter 'cpusets' sure is popular ;).

If cpusets were somehow to be subsumed into CKRM, it would likely have
meant reincarnating cpusets in a new form, varying in some degree, large
or small, from its current form.  If that had been in our forseeable
future, then we would not have wanted to put cpusets in its current form
in the main tree.  It's alot easier to change API's that aren't API's
yet.

I remain certain that cpusets don't fit in CKRM.  Not even close.

The merger of cpusets and sched domains is an entirely different affair,
in my view.  It's an internal optimization, having next to zero impact
on any API's that the kernel presents to userland.  On most systems, it
would be of no particular benefit.  But on big honkin numa boxes making
heavy use of cpusets, it might make the schedulers work more efficient. 
Or might not.  I will leave that up to others to figure out, when and if
they choose to.  I'll be glad to help with such an effort, what little
I can, if it comes about.

If such an integration between cpusets and sched domains is in our
future, we should first get cpusets into the kernel, and then the
appropriate experts can refine the interaction of cpusets with sched
domains.  In this case, the sooner cpusets goes in, the better, so that
the integration effort with sched domains can commence, confident that
cpusets are here to stay.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401