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

Shailabh Nagar
2005-02-08T23:58:07Z

>> 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