[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.029 / U:0.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site