lkml.org 
[lkml]   [2013]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] sched: Reduce overestimating avg_idle
From
Date

> 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




\
 
 \ /
  Last update: 2013-08-01 10:01    [W:0.297 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site