From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755087AbbDUME1 (ORCPT ); Tue, 21 Apr 2015 08:04:27 -0400 Received: from www.linutronix.de ([62.245.132.108]:57816 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752005AbbDUMEZ (ORCPT ); Tue, 21 Apr 2015 08:04:25 -0400 Date: Tue, 21 Apr 2015 14:04:41 +0200 (CEST) From: Thomas Gleixner To: "Paul E. McKenney" cc: LKML , Peter Zijlstra , Ingo Molnar , Preeti U Murthy , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker , Josh Triplett , Lai Jiangshan , John Stultz , Marcelo Tosatti Subject: Re: [patch 20/39] tick: nohz: Rework next timer evaluation In-Reply-To: <20150416164216.GA23685@linux.vnet.ibm.com> Message-ID: References: <20150414203303.702062272@linutronix.de> <20150414203502.184198593@linutronix.de> <20150416164216.GA23685@linux.vnet.ibm.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Apr 2015, Paul E. McKenney wrote: > > @@ -1508,11 +1509,12 @@ int rcu_needs_cpu(unsigned long *dj) > > > > /* Request timer delay depending on laziness, and round. */ > > if (!rdtp->all_lazy) { > > - *dj = round_up(rcu_idle_gp_delay + jiffies, > > + dj = round_up(rcu_idle_gp_delay + jiffies, > > rcu_idle_gp_delay) - jiffies; > > } else { > > - *dj = round_jiffies(rcu_idle_lazy_gp_delay + jiffies) - jiffies; > > + dj = round_jiffies(rcu_idle_lazy_gp_delay + jiffies) - jiffies; > > } > > + *nextevt = basemono + dj * TICK_NSEC; > > The multiply would have been a problem back in the day, but should > be just fine on modern hardware. I suppose that slow hardware could > compensate by having the scheduling-clock period be an exact power of > two worth of nanoseconds. I don't think the extra multiply matters much. round_up() and round_jiffies() are way more expensive ... > > #ifdef CONFIG_NO_HZ_FULL > > + /* Limit the tick delta to the maximum scheduler deferment */ > > if (!ts->inidle) > > - time_delta = min(time_delta, scheduler_tick_max_deferment()); > > + delta = min(time_delta, scheduler_tick_max_deferment()); > > s/time_delta/delta/? Doh, yes. Btw. Could you please trim your replies? It's hard to find the single line comment when forced to scroll down several pages. Thanks, tglx