Re: [ckrm-tech] merging hierarchical resource class design and CKRMv3

Rik van Riel wrote:
>On Tue, 10 Feb 2004, Hubertus Franke wrote:
>
>
>>Absolute shares and proportional shares are "equivalent" just with
>>respect to a different base. Absolute shares are relative to a 100% base,
>>
>
>>This can be done at limit/share set time. I don't see a problem here.
>>But the problem persists with "don't care".
>>
>
>Right ... the solution is simple. The proportions are relative
>to the weight assigned to the root. At that point we've got the
>same code as absolute shares, except we're no longer stuck to
>100%, but could have any N out of M shares assigned...
>
>In the remaining CPU time all tasks (both those from resource
>groups with CPU guarantees and those from "don't care" groups)
>would get scheduled.
>
>This would lead to the following CPU scheduling hierarchy:
>- tasks from groups where use < guarantee
>- tasks from groups where use < limit, or tasks from "don't care" groups
>- tasks from groups where use > limit (only if the system is really idle)
>
>Being a renewable resource, nobody would get starved from the CPU.
>
if the following hierarchy is defined, *with all shares being proportional*
/class_A 20
/A1 : 40
/A2 : 30
/A3 : "don't care"
/class B 20
how does the CPU sched know how much to assign to A3 unless we have a
clearly defined "default share" value associated with class_A ? Its
clear that class_A's share is 20/20+20 = 50% of (say a single) CPU but
not what A3's share of that 50% is.
The problem doesn't exist if both A1, A2 use only absolute shares (then
A3 is clearly 100%-sum). But if any one
of A1, A2 is proportional, we need a default share value.
Are you suggesting we use A's 20 value directly to deduce A3's share is
20/(20+30+40) ?
Please clarify further.
-- Shailabh