Re: [ckrm-tech] [PATCH 0/4] sched: Add CPU rate caps

[Peter Williams]

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@xxxxxxxxxxxxxx

"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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/