lkml.org 
[lkml]   [2011]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: CFS Bandwidth Control - Test results of cgroups tasks pinned vs unpinnede
    From
    Date
    On Tue, 2011-09-13 at 21:51 +0530, Srivatsa Vaddagiri wrote:
    > > which increases the time you force a task to sleep that's holding locks etc..
    >
    > Ideally all tasks should get capped at the same time, given that there is
    > a global pool from which everyone pulls bandwidth? So while one vcpu/task
    > (holding a lock) gets capped, other vcpus/tasks (that may want the same lock)
    > should ideally not be running for long after that, avoiding lock inversion
    > related problems you point out.

    No this simply cannot be true.. You force groups to sleep so that other
    groups can run, right? Therefore shared kernel locks will cause
    inversion.

    You cannot put both groups to sleep and still expect a utilization of
    100%.

    Simple example, some task in group A owns the i_mutex of a file, group A
    runs out of time and gets dequeued. Some other task in group B needs
    that same i_mutex.

    > I guess that we may still run into that with current implementation ..
    > Basically global pool may have zero runtime left for current period,
    > forcing a vcpu/task to be throttled, while there is surplus runtime in
    > per-cpu pools, allowing some sibling vcpus/tasks to run for wee bit
    > more, leading to lock-inversion related problems (more idling). That
    > makes me think we can improve directed yield->capping interaction.
    > Essentially when the target task of directed yield is capped, can the
    > "yielding" task donate some of its bandwidth?

    What moron ever calls yield anyway? If you use yield you're doing it
    wrong!


    \
     
     \ /
      Last update: 2011-09-13 18:35    [W:0.200 / U:0.012 seconds]
    ©2003-2014 Jasper Spaans. Advertise on this site