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 [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
