linux-kernel - Re: [BUG, bisect] hrtimer: severe lag after suspend & resume

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 5 Jun 2015 12:07:07 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	John Stultz <john.stultz@...aro.org>,
	Jeremiah Mahler <jmmahler@...il.com>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [BUG, bisect] hrtimer: severe lag after suspend & resume


* Thomas Gleixner <tglx@...utronix.de> wrote:

> On Thu, 4 Jun 2015, John Stultz wrote:
> > On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler <jmmahler@...il.com> wrote:
> > So I suspect the problem is the change to clock_was_set_seq in
> > timekeeping_update is done prior to mirroring the time state to the
> > shadow-timekeeper. Thus the next time we do update_wall_time() the
> > updated sequence is overwritten by whats in the shadow copy. The
> > attached patch moving the modification up seems to avoid the issue for
> > me.
> 
> Duh, yes.
>  
> > Thomas: Looking at the problematic change, I'm not a big fan of it. Caching 
> > timekeeping state here in the hrtimer code has been a source of bugs in the 
> > past, and I'm not sure I see how avoiding copying 24bytes is that big of a 
> > win. Especially since it adds more state to the timekeeper and hrtimer base 
> > that we have to read and mange.
> 
> It's not about copying 24 bytes. It's about touching 3 cache lines for nothing. 
> In situations where we run high frequency periodic timers on clock monotonic and 
> nothing is going on in the other clock domains, which is a pretty common 
> situation, this is measurable in terms of cache utilization. [...]

It's not just about 'touching': it's about _dirtying_ cachelines from a globally 
executed function (timekeeping), which is then accessed by per-CPU functionality 
(hrtimers).

That makes it far more expensive, it has similar scalability limiting effects as a 
global lock - while if we do it smart it can perform as essentially lockless code 
in most cases.

Thanks,

	Ingo
--
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/