`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" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`