Re: [RFC] CPU controllers?

["Chris Friesen" <cfriesen@nortel.com>]

Nick Piggin wrote:

> So, from my POV, I would like to be convinced of the need for this first.
> I would really love to be able to keep core kernel simple and fast even if
> it means edge cases might need to use a slightly different solution.

We currently use a heavily modified CKRM version "e".

The "resource groups" (formerly known as CKRM) cpu controls express what 
we'd like to do, but they aren't nearly accurate enough.  We don't make 
use the limits, but we do use per-cpu guarantees, along with the 
hierarchy concept.

Our engineering guys need to be able to make cpu guarantees for the 
various type of processes.  "main server app gets 90%, these fault 
handling guys normally get 2% but should be able to burst to 100% for up 
to 100ms, that other group gets 5% in total, but a subset of them should 
get priority over the others, and this little guy here should only be 
guaranteed .5% but it should take priority over everything else on the 
system as long as it hasn't used all its allocation".

Ideally they'd really like sub percentage (.1% would be nice, but .5% is 
proably more realistic) accuracy over the divisions.  This should be 
expressed per-cpu, and tasks should be migrated as necessary to maintain 
fairness.  (Ie, a task belonging to a group with 50% on each cpu should 
be able to run essentially continuously, bouncing back and forth between 
cpus.)  In our case, predictability/fairness comes first, then performance.

If a method is accepted into mainline, it would be nice to have NPTL 
support it as a thread attribute so that different threads can be in 
different groups.

Chris