Re: RFC for a new Scheduling policy/class in the Linux-kernel

[Raistlin <raistlin@linux.it>]

[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

On Thu, 2009-07-16 at 10:58 +0200, Peter Zijlstra wrote:
> Right so control-groups (cgroups for short) are a form of
> virtualization. Each controller is specific to a resource. We have
> memory controllers, namespace controllers and also a scheduler
> controller.
> 
> If you would apply all controllers to the same task groups you get a
> result like chroot on steroids, or jails etc. But you can also use them
> individually to control resources in creative ways.
> 
> In order to manage RT resources you want:
> 
>   - a minimum bandwidth guarantee
>   - isolation
> 
> So ideally you want a CBS server that schedules your RT (FIFO/RR) tasks.
> 
Or, maybe, an RT fix-priority RT scheduling class (for FIFO/RR tasks)
with some kind of bandwidth limiting fix-priority algorithm for groups,
such as deferrable server (which is basically what you have now) or,
sporadic server.

What do you think about this?

The only thing you need to have this working is adding the capability of
explicitly assigning priorities to groups!
I'm sending some code for this in the next days... It has some (even
serious) issues, or at least some features that would need discussing
about, but it's a start.

Obviously, you can also have EDF in place, maybe as a different
scheduling class than sched-rt, able to accomodate EDF tasks, if wanted,
or again FIFO and RR task sets ("ghosts"), as in Fabio's proposal.

To me, this seems the very best solution both for real-time people
(which will get FP and EDF!) and for other users... And it also makes it
easier to retain POSIX compatibility (if the system is properly
configured) than if we add deadlines to sched-rt groups.

But that's only my very humble opinion. :-D

> Furthermore the whole feature is still marked EXPERIMENTAL, basically
> because I do recognize it for the hack it is -- that said, some people
> might find it useful.
> 
Hey, it is very useful for me actually!! Without it I would be sleeping
right now... And not here coding and answering mails at this late time
in the night!! :-P

> These groups get assigned a bandwidth through the use of a period and
> runtime group parameter -- the documentation states that using different
> periods is currently broken and would require a deadline server.
> 
Or a priority, since we are in the fixed priority scheduling class?

> Therefore we can assume all periods are equal, for the rest of this
> description -- and set it to 1s.
> 
> 
> So what does it do, its a hierarchical FIFO scheduler, with the prio of
> a group being that of the max prio of its children. If a group runs out
> of quota it will be dequeued. When the period timer comes along and
> refreshes the quota it will be requeued.
> 
>       R
>      / \
>     A   B
>    / \  |\
>   1   4 C 3
>         |
>         2
> 
> groups in letters, tasks in digits.
>
> [...]
>
WoW!! Very nice, thorough and clear explanation... Consider adding it to
Documentation/! :-D

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@ekiga.net /
dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]