From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752240AbcFNKPK (ORCPT ); Tue, 14 Jun 2016 06:15:10 -0400 Received: from ns.sciencehorizons.net ([71.41.210.147]:58127 "HELO ns.sciencehorizons.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751488AbcFNKPI (ORCPT ); Tue, 14 Jun 2016 06:15:08 -0400 Date: 14 Jun 2016 06:15:06 -0400 Message-ID: <20160614101506.30068.qmail@ns.sciencehorizons.net> From: "George Spelvin" To: linux@sciencehorizons.net, tglx@linutronix.de Subject: Re: [patch 13/20] timer: Switch to a non cascading wheel Cc: edumazet@google.com, linux-kernel@vger.kernel.org, peterz@infradead.org, richardcochran@gmail.com In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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!