Re: [CFS Bandwidth Control v4 5/7] sched: add exports tracking cfsbandwidth control statistics
From: Paul Turner
Date: Thu Feb 24 2011 - 22:26:50 EST
On Wed, Feb 23, 2011 at 5:32 AM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
> On Tue, 2011-02-15 at 19:18 -0800, Paul Turner wrote:
>> + raw_spin_lock(&cfs_b->lock);
>> + cfs_b->throttled_time += (rq->clock - cfs_rq->throttled_timestamp);
>> + raw_spin_unlock(&cfs_b->lock);
> That seems to put the cost of things on the wrong side. Read is rare,
> update is frequent, and you made the frequent thing the most expensive
Hum.. the trade-off here is non-trivial I think
- This update is only once per-quota period (*if* we throttled within
that period). This places the frequency in the 10s-100s of ms range.
- Sampling would probably occur on an order of once a second (assuming
some enterprise management system that cares about these statistics).
If we make the update cheaper by moving this per-cpu, then yes the
updates are cheaper but the reads now having per-cpu cost makes the
overall cost about the same (multiplying frequency by delta cost).
We could move the global accrual to an atomic, but this isn't any
cheaper given that this lock shouldn't be
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/