> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
