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

[Shailabh Nagar <nagar@watson.ibm.com>]

>> As best as I can figure out, CKRM is a fair share scheduler with a
>> gussied up more modular architecture, so that the components to track
>> usage, control (throttle) tasks, and classify tasks are separate
>> plugins.  

 > I'm not an expert on CKRM, so I'll leave the refuting (or notrefuting)
 > of your claims as to CKRM's usefulness to someone with more background
 > and expertise on the subject.  Anyone want to pipe up and defend the
 > alleged "gussied up" fair-share scheduler?

Well, I'm not sure I want to minutely examine Paul's choice of words !
I would have thought that two OLS and one KS presentation would suffice 
to clarify what CKRM is and isn't but that doesn't seem to be the case 
:-) So here we go again

CKRM is both a resource management infrastructure AND
a set of controllers. The two are independent.

The infrastructure provides for
a) grouping of kernel objects (currently only tasks & sockets but can be 
extended to any others)
b) an external interface for manipulating attributes of the grouping 
such as shares, statistics and members
c) an internal interface for controllers to exploit this grouping 
information in whatever way it wants.

The controllers do whatever they want with the grouping info.
The IBM folks on the project have written ONE set of controllers for 
cpu, mem, io, net and numtasks which HAPPENS to be/aspire to be 
fair-share. Others are free to write ones which ignore share settings 
and be unfair, callous or whatever else they want.

We would love to have people write alternate controllers for the same 
resources (cpu,mem,io,net,numtasks) and others. The former will provide 
alternatives to our implementation, the latter will validate the 
architecture's utility.


>> I can find no significant and useful overlap on any of these
>> fronts, either the existing plugins or their infrastructure, with what
>> cpusets has and needs.
>> There are claims that CKRM has some generalized resource management
>> architecture that should be able to handle cpusets needs, but despite my
>> repeated (albeit not entirely successful) efforts to find documentation
>> and read source and my pleadings with Matthew and earlier on this
>> thread, I was never able to figure out what this meant, or find anything
>> that could profitably integrate with cpusets.

Rereading the earlier posts on the thread, I'd agree. There are some 
similarities in our interfaces but not enough to warrant a merger.


-- Shailabh