Messages in this thread | | | Subject | Re: [RFC PATCH] sched: Reduce overestimating avg_idle | From | Jason Low <> | Date | Thu, 01 Aug 2013 00:36:41 -0700 |
| |
> I wonder if we could get even more conservative values > of avg_idle by clamping delta to max, before calling > update_avg... > > Or rather, I wonder if that would matter enough to make > a difference, and in what direction that difference would > be. > > In other words: > > if (rq->idle_stamp) { > u64 delta = rq->clock - rq->idle_stamp; > u64 max = (sysctl_sched_migration_cost * 3) / 2; > > if (delta > max) > delta = max; > > update_avg(&rq->avg_idle, delta); > rq->idle_stamp = 0; > }
Yes, I initially tried to limit delta to the max. That helped keep the avg_idle smaller and provided even better performance improvements on the 8 socket HT-enabled case. Here were some of those performance boosts on AIM7:
alltests: +14.5% custom: +15.9% disk: +15.9% fserver: +33.7% new_fserver: +15.7% high_systime: +16.7% shared: +14.1%
When we limit the average instead of the delta, the performance boosts were in the range of 5-10%, with the exception of fserver.
I initially thought that limiting delta to a small value might cause the average to often be underestimated. But come to think of it, this might actually provide a more accurate estimate of whether the majority of idle durations are either less than or greater than migration_cost. Idle durations can be a lot higher while there's a limit to how small each short idle duration is. This may help offset some of that bias towards a high avg.
So how acceptable is setting a limit of 2*migration cost or less on the delta rather than on the avg?
Thanks, Jason
| |