lkml.org 
[lkml]   [2006]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ckrm-tech] [PATCH 0/4] sched: Add CPU rate caps
Balbir Singh wrote:
> Peter Williams wrote:
>> Balbir Singh wrote:
>>
>>> Peter Williams wrote:
>>>
>>>> Balbir Singh wrote:
>>>>
>>>>> Peter Williams wrote:
>>>>>
>>>
>>> <snip>
>>>
>>>>> Is it possible that the effective tasks
>>>>> is greater than the limit of the group?
>>>>
>>>>
>>>>
>>>> Yes.
>>>>
>>>>> How do we handle this scenario?
>>>>
>>>>
>>>>
>>>> You've got the problem back to front. If the number of effective
>>>> tasks is less than the group limit then you have the situation that
>>>> needs special handling (not the other way around). I.e. if the
>>>> number of effective tasks is less than the group limit then
>>>> (strictly speaking) there's no need to do any capping at all as the
>>>> demand is less than the limit. However, in the case where the group
>>>> limit is less than one CPU (i.e. less than 1000) the recommended
>>>> thing to do would be set the limit of each task in the group to the
>>>> group limit.
>>>>
>>>> Obviously, group limits can be greater than one CPU (i.e. 1000).
>>>>
>>>> The number of CPUs on the system also needs to be taken into account
>>>> for group capping as if the group cap is greater than the number of
>>>> CPUs there's no way it can be exceeded and tasks in this group would
>>>> not need any processing.
>>>>
>>>
>>> What if we have a group limit of 100 (out of 1000) and 150 effective
>>> tasks in
>>> the group? How do you calculate the cap of each task?
>>
>>
>> Personally I'd round up to 1 :-) but rounding down to zero is also an
>> option. The reason I'd opt for 1 is that a zero cap has a special
>> meaning i.e. background.
>>
>>> I hope my understanding of effective tasks is correct.
>>
>>
>> Yes, but I think that you fail to realize that this problem (a lower
>> limit to what caps can be enforced) exists for any mechanism due to
>> the fact we're stuck with discrete mathematics in computers. This
>> includes floating point representations of numbers which are just
>> crude (discrete maths) approximations of real numbers.
>
> I do appreciate and realize the problem, thats why I asked the question.
>
> There are some ways of solving this problem (that I could think about)
>
> 1. Keep a whole number and fraction pair and increment the fraction until
> it reaches a whole number and then schedule the task when the whole
> number value reaches a minimal threshold. Or provide tasks with some
> minimal whole number ticks in advance and then do not schedule them
> again till their fractions add up to the whole number (credit system).
>
> For example if T1 and T2 have a cap of 0.5%. Then represent the values
> as whole number zero and fraction represented as 1 and divisor as 2.
>
> Every two ticks their whole number would become 1 and fraction 0,
> divisor 2.
> Schedule the tasks for a tick whenever its whole number becomes 1
> and reset then its whole number to 0.

You're over engineering and you're not solving the problem. You're just
moving it down a bit.

>
>
> 2. In a group based cap management system, schedule some tasks (highest
> priority)
> until their cap run out. In the subsequent rounds pick and choose
> tasks that
> did not get a chance to run earlier.
>
> Solving this is indeed a interesting problem.
>

Once again, you're over engineering and probably making the problem worse.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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/

\
 
 \ /
  Last update: 2006-06-19 13:38    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site