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

[Dhaval Giani <dhaval.giani@gmail.com>]

On Thu, Jul 16, 2009 at 4:04 AM, Ted Baker<baker@cs.fsu.edu> wrote:
> On Wed, Jul 15, 2009 at 03:53:33PM -0600, Chris Friesen wrote:
>
>> >From an API standpoint, the "group scheduling" functionality in linux
>> allows for the creation of an arbitrary hierarchy of groups, each of
>> which may contain zero or more tasks.  (Each task is associated with
>> exactly one group.)
>>
>> There is a distinction between groups containing realtime tasks, and
>> groups containing non-realtime tasks.  For realtime groups, each group
>> is allocated a specific amount of cpu time.  For non-realtime groups,
>> each group is allocated a specific weight.
>>
>> A realtime group may use up to its specified amount of cpu time.  Any
>> cpu time not used by a realtime group is distributed to the non-realtime
>> groups according to their relative weights.
>>
>> This does add a whole different API to the mix, but allows for controls
>> to be set by the administrator on existing POSIX apps without needing to
>> recompile them.
>
> This is in the right direction, but there is a lot about Linux groups
> that I either do not understand or which falls short of what is needed.
> Perhaps you can point me to an up to date detailed explanation of
> how they work?
>
> From what I've been able to infer from my brief foray into that
> part of the kernel code (a year ago), there seemed to be several
> aspects of the group scheduling that did not seem to admit
> schedulability analysis.  (I admit that I may have read it wrong,
> and these statements are false.)
>
> 1) The priority of a group seemed to be defined by the priority of
> the highest-priority thread in the group's run-queue, which means
> it varies dynamically according to which threads in the group are
> contending.
>

This is true, but it also ensures that the time allocated to the group
is also consumed by group if it wants to.

> 2) Budget enforcement seemed to only occur at system tick
> boundaries, which means precision can only be achieved at the cost
> of frequent clock interrupts.
>
> 3) It seemed that a thread could belong to more than one group,
> and so distributed charges arbitrarily between groups.
> If so, budget allocation would seem very difficult.
>

No. A thread can only be a part of one group at a time.

> 4) On an SMP, more than one thread could be running against
> the same budget at the same time, resulting in budget over-charges.
>

The rt group scheduler does split the budget per cpu. On expiring the
budget, it tries to borrow from other CPUs if possible.

Thanks,
Dhaval
-- 

Spike Milligan  - "All I ask is the chance to prove that money can't
make me happy." -
http://www.brainyquote.com/quotes/authors/s/spike_milligan.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html