[lkml]   [2006]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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 Williams

"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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-19 13:38    [W:0.072 / U:3.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site