Messages in this thread | | | From | Paul Turner <> | Date | Tue, 28 Jun 2011 20:37:19 -0700 | Subject | Re: [patch 09/16] sched: unthrottle cfs_rq(s) who ran out of quota at period refresh |
| |
On Tue, Jun 28, 2011 at 2:11 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > On Mon, 2011-06-27 at 21:40 -0700, Paul Turner wrote: >> >> + if (unlikely(runtime_expires != cfs_b->runtime_expires)) >> >> + goto out_unlock; >> > >> > it might help to explain how, runtime_expires is taken from cfs_b after >> > calling __refill_cfs_bandwidth_runtime, and we're in the replenishment >> > timer, so nobody is going to be adding new runtime. >> > >> >> Good idea -- thanks > > Aside from being a good idea, I'm genuinely puzzled by that part and > would love having it explained :-) >
It's all the users fault!
While we were busy doing this they might have set some new bandwidth limit (since we drop cfs_b->lock to distribute) via cgroupfs, in which case we need to make sure we:
a) stop since setting the new runtime will have unthrottled everyone anyway b) don't put our runtime in cfs_b->runtime as at this point we'd be over-writing the new-runtime just set by tg_set_cfs_bandwidth
We can catch this happening however, since tg_set_cfs_bandwidth sets a new expiration' which is what the check above enforces. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |