linux-kernel - Re: [patch 13/20] timer: Switch to a non cascading wheel

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:	14 Jun 2016 06:15:06 -0400
From:	"George Spelvin" <linux@...encehorizons.net>
To:	linux@...encehorizons.net, tglx@...utronix.de
Cc:	edumazet@...gle.com, linux-kernel@...r.kernel.org,
	peterz@...radead.org, richardcochran@...il.com
Subject: Re: [patch 13/20] timer: Switch to a non cascading wheel

On Tue, 14 Jun 2016, Thomas Gleixner wrote:
> I thought about that and when looking at those long timeout thingies
> I came to the conclusion that it's simply not worth the trouble.

Okay.  A comment might be nice, just to stop someone else wasting
brain power on it.  E.g.

/*
 * If the timer happens to expire exactly now, this will cascade it to
 * vectors[0] which we just cleared and won't check again for 64 jiffies.
 * This is acceptable error on a timeout this long.
 */

>> to be replaced with __builtin_clz or similar:
> 
> Except that __fls() is noticeably slower than the if chain.

Fair enogh.  I wasn't sure about the distribution; if it's biased low,
then the if chain would win.

> That's not new code. We kept the ordering, but yes, we definitely can turn
> that around. The only restriction is that we get it before releasing the lock.

Thanks!