Re: [RFC 0/5] sched: Add CPU rate caps

[Sam Vilain <sam@vilain.net>]

Peter Williams wrote:

>>I'd certainly be interested in having a look through the split out patch
>>to see how namespaces and this advanced scheduling system might
>>interoperate.
>>    
>>
>
>OK.  I've tried very hard to make the scheduling code orthogonal to 
>everything else and it essentially separates out the scheduling within a 
>CPU from other issues e.g. load balancing.  This separation is 
>sufficiently good for me to have merged PlugSched with an earlier 
>version of CKRM's CPU management module in a way that made each of 
>PlugSched's schedulers available within CKRM's infrastructure.  (CKRM 
>have radically rewritten their CPU code since then and I haven't 
>bothered to keep up.)
>
>The key point that I'm trying to make is that I would expect PlugSched 
>and namespaces to coexist without any problems.  How it integrates with 
>the "advanced" scheduling system would depend on how that system alters 
>things such as load balancing and/or whether it goes for scheduling 
>outcomes at a higher level than the task.
>  
>

Coexisting is the base line and I don't think they'll 'interfere' with
each other, per se, but we specifically want to make it easy for
userland to set up and configure scheduling policies to apply to groups
of processes.

For instance, the vserver scheduling extension I wrote changes
scheduling policy so that the interactivity bonus is reduced to -5 ..
-5, and -5 .. +15 is given as a bonus or penalty for an entire vserver
that is currently below or above its allocated CPU quotient.  In this
case the scheduling algorithm hasn't changed, just more feedback is
given into the effective priorities of the processes being scheduled. 
ie, there are now two "inputs" (task and vserver) to the existing scheduler.

I guess the big question is - is there a corresponding concept in
PlugSched?  for instance, is there a reference in the task_struct to the
current scheduling domain, or is it more CKRM-style with classification
modules?

If there is a reference in the task_struct to some set of scheduling
counters, maybe we could squint and say that looks like a namespace, and
throw it into the nsproxy.

>I'm assuming that you're happy to wait for the next release?  That will 
>improve the likelihood of descriptions in the patches :-).
>  
>

Let's keep it the technical dialogue going for now, then.

Now, forgive me if I'm preaching to the vicar here, but have you tried
using Stacked Git for the patch development?  I find the way that you
build patch descriptions as you go along, can easily wind the commit
stack to work on individual patches and import other people's work to be
very simple and powerful.

  http://www.procode.org/stgit/

I just mention this because you're not the first person I've talked to
using Quilt to express some difficulty in producing incremental patchset
snapshots.  Not having used Quilt myself I'm unsure whether this is a
deficiency or just "the way it is" once a patch set gets big.

Sam.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/