[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
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

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

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

 \ /
  Last update: 2011-09-13 18:35    [W:0.102 / U:1.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site