lkml.org 
[lkml]   [2011]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [tip:sched/core] sched: Untangle cpu-load and timekeeping code
From
Date
On Thu, 2011-01-27 at 14:55 +0800, Yong Zhang wrote:
> On Thu, Jan 27, 2011 at 4:03 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >> We should not do this checking any more. In normal case,
> >> it will always return false.
> >> If it indeed returns true for some reason, we will lose the
> >> timer forever.
> >
> > Its needed for the nohz case, arguably we could move it inside
> > calc_global_nohz().
>
> I have no idea why we need that checking in calc_global_nohz().
>
> Before this patch, time_before(jiffies, calc_load_update) is
> needed in calc_global_nohz() because it will reduce the ovehead
> on dealing with calc_load_fold_idle if we have idle dance in one
> LOAD_FREQ.
>
> Now we have calc_global_load() called at every LOAD_FREQ
> instead of every tick, that problem is gone.

It was (the patch has been killed due to the nohz problem you pointed
out) because it could hit at an arbitrary long interval due to it being
a deferred timer.



----|---------|---------|-----
^ ^ ^
t0 t1 t2

Suppose the cpu goes into nohz at t0, and wakes up at t{1,2}, spanning
{2,3} LOAD_FREQ boundaries, then the code in calc_global_nohz does:
n := (t{1,2}-t0)/LOAD_FREQ and finds 2, the check you refer to will make
the difference between t1 and t2 and will for t2 apply the 3rd period.

But you were right in pointing out that missing the mod_timer() call in
that case would have been disastrous.

Anyway, its all moot since the patch is gone now.




\
 
 \ /
  Last update: 2011-01-28 13:43    [W:0.038 / U:13.540 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site