[lkml]   [2009]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/2] sched: fix nr_uninterruptible accounting of frozen tasks really
    On Fri, 17 Jul 2009, Peter Zijlstra wrote:

    > On Fri, 2009-07-17 at 12:25 +0000, Thomas Gleixner wrote:
    > > plain text document attachment (freezer-fix-accounting-for-real.patch)
    > > commit e3c8ca8336 (sched: do not count frozen tasks toward load) broke
    > > the nr_uninterruptible accounting on freeze/thaw. On freeze the task
    > > is excluded from accounting with a check for (task->flags &
    > > PF_FROZEN), but that flag is cleared before the task is thawed. So
    > > while we prevent that the freezing task with state
    > > TASK_UNINTERRUPTIBLE is accounted to nr_uninterruptible we decrement
    > > nr_uninterruptible on thaw.
    > >
    > > Use a separate flag which is handled by the freezing task itself. Set
    > > it before calling the scheduler with TASK_UNINTERRUPTIBLE state and
    > > clear it after we return from frozen state.
    > Right, so I'm wondering why we don't fully revert e3c8ca8336 to begin
    > with.

    Fine with me, but it seems that the cgroup folks have some luser space
    stuff looking at proc/loadavg which goes berserk when loadavg
    increases rapidly due to freezing. OTOH that stuff seems to be
    oblivious to the fact that the commit in question brings loadavg
    irreversibly to 0 when you do enough freeze/thaw cycles.

    So either we revert or apply the fix, which keeps the accounting
    straight and solves the freezer loadavg thing. No strong opinion on



     \ /
      Last update: 2009-07-17 14:53    [W:0.020 / U:36.816 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site