lkml.org 
[lkml]   [2011]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 14/15] sched: return unused runtime on voluntary sleep
    (2011/05/03 18:29), Paul Turner wrote:
    > When a local cfs_rq blocks we return the majority of its remaining quota to the
    > global bandwidth pool for use by other runqueues.
    >
    > We do this only when the quota is current and there is more than
    > min_cfs_rq_quota [1ms by default] of runtime remaining on the rq.
    >
    > In the case where there are throttled runqueues and we have sufficient
    > bandwidth to meter out a slice, a second timer is kicked off to handle this
    > delivery, unthrottling where appropriate.
    >
    > Using a 'worst case' antagonist which executes on each cpu
    > for 1ms before moving onto the next on a fairly large machine:
    >
    > no quota generations:
    > 197.47 ms /cgroup/a/cpuacct.usage
    > 199.46 ms /cgroup/a/cpuacct.usage
    > 205.46 ms /cgroup/a/cpuacct.usage
    > 198.46 ms /cgroup/a/cpuacct.usage
    > 208.39 ms /cgroup/a/cpuacct.usage
    > Since we are allowed to use "stale" quota our usage is effectively bounded by
    > the rate of input into the global pool and performance is relatively stable.
    >
    > with quota generations [1s increments]:
    > 119.58 ms /cgroup/a/cpuacct.usage
    > 119.65 ms /cgroup/a/cpuacct.usage
    > 119.64 ms /cgroup/a/cpuacct.usage
    > 119.63 ms /cgroup/a/cpuacct.usage
    > 119.60 ms /cgroup/a/cpuacct.usage
    > The large deficit here is due to quota generations (/intentionally/) preventing
    > us from now using previously stranded slack quota. The cost is that this quota
    > becomes unavailable.
    >
    > with quota generations and quota return:
    > 200.09 ms /cgroup/a/cpuacct.usage
    > 200.09 ms /cgroup/a/cpuacct.usage
    > 198.09 ms /cgroup/a/cpuacct.usage
    > 200.09 ms /cgroup/a/cpuacct.usage
    > 200.06 ms /cgroup/a/cpuacct.usage
    > By returning unused quota we're able to both stably consume our desired quota
    > and prevent unintentional overages due to the abuse of slack quota from
    > previous quota periods (especially on a large machine).
    >
    > Signed-off-by: Paul Turner <pjt@google.com>
    >
    > ---

    Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

    Thanks,
    H.Seto



    \
     
     \ /
      Last update: 2011-05-10 09:31    [W:4.323 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site