lkml.org 
[lkml]   [2009]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC v4 PATCH 3/7] sched: Enforce hard limits by throttling
    On Fri, Dec 04, 2009 at 05:09:55PM +0100, Peter Zijlstra wrote:
    > On Tue, 2009-11-17 at 20:05 +0530, Bharata B Rao wrote:
    > > sched: Enforce hard limits by throttling.
    > >
    > > From: Bharata B Rao <bharata@linux.vnet.ibm.com>
    > >
    > > Throttle the task-groups which exceed the runtime allocated to them.
    > > Throttled group entities are removed from the run queue.
    >
    > This patch is just vile, all those _locked variants should really go.
    >
    > Nor it is entirely clear why they're there.
    >

    update_curr() is the place where I check if the group has exceeded its
    runtime and it needs to take cfs_rq->cfs_runtime_lock. However there are
    2 places from where update_curr() gets called with cfs_rq->cfs_runtime_lock
    already held. Hence _locked() version of update_curr() exists.

    These two call paths are both enqueue paths (enqueue_task_fair and
    enqueue during unthrottling when period timer fires). Hence _locked()
    versions of entity_enqueue() exists.

    I see that you don't have this sort of requirement (of holding
    rt_rq->rt_runtime_lock) in rt. I will recheck on this one to see why you are
    able to do this in rt and I can't in cfs. If convinced, I shall get rid
    _locked versions.

    Thanks Peter for taking time to review the hard limit patches.

    Regards,
    Bharata.


    \
     
     \ /
      Last update: 2009-12-05 14:05    [W:6.886 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site