linux-kernel - Re: [tip:sched/core] sched: Untangle cpu-load and timekeeping code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1296214483.15234.313.camel@laptop>
Date:	Fri, 28 Jan 2011 12:34:43 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Yong Zhang <yong.zhang0@...il.com>
Cc:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched: Untangle cpu-load and timekeeping code

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@...llo.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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/