From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754697AbbDTLQl (ORCPT ); Mon, 20 Apr 2015 07:16:41 -0400 Received: from e18.ny.us.ibm.com ([129.33.205.208]:44930 "EHLO e18.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753487AbbDTLQk (ORCPT ); Mon, 20 Apr 2015 07:16:40 -0400 Message-ID: <5534E00F.2040606@linux.vnet.ibm.com> Date: Mon, 20 Apr 2015 16:46:31 +0530 From: Preeti U Murthy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Gleixner , LKML CC: Peter Zijlstra , Ingo Molnar , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker Subject: Re: [patch 10/39] hrtimer: Use cpu_base->active_base for hotpath iterators References: <20150414203303.702062272@linutronix.de> <20150414203501.322887675@linutronix.de> In-Reply-To: <20150414203501.322887675@linutronix.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15042011-0033-0000-0000-0000006A140C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/15/2015 02:38 AM, Thomas Gleixner wrote: >>Now that we have the active_bases field in sync we can use it for This sentence appears a bit ambiguous. I am guessing you are referring to what the first patch in this series did, in which case wouldn't it be better if it is stated a bit more elaborately like 'Now that it is guaranteed that active_bases field will be in sync with the timerqueue on the corresponding clock base' ? It took me a while to figure out what the statement was referring to. >>iterating over the clock bases. This allows to break out early if no >>more active clock bases are available and avoids touching the cache >>lines of inactive clock bases. >> >>Signed-off-by: Thomas Gleixner >>--- Regards Preeti U Murthy >> kernel/time/hrtimer.c | 17 ++++++++--------- >> 1 file changed, 8 insertions(+), 9 deletions(-) >> >>Index: tip/kernel/time/hrtimer.c >>=================================================================== >>--- tip.orig/kernel/time/hrtimer.c >>+++ tip/kernel/time/hrtimer.c >>@@ -419,16 +419,16 @@ static ktime_t __hrtimer_get_next_event( >> { >> struct hrtimer_clock_base *base = cpu_base->clock_base; >> ktime_t expires, expires_next = { .tv64 = KTIME_MAX }; >>- int i; >>+ unsigned int active = cpu_base->active_bases; >> >>- for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++, base++) { >>+ for (; active; base++, active >>= 1) { >> struct timerqueue_node *next; >> struct hrtimer *timer; >> >>- next = timerqueue_getnext(&base->active); >>- if (!next) >>+ if (!(active & 0x01)) >> continue; >> >>+ next = timerqueue_getnext(&base->active); >> timer = container_of(next, struct hrtimer, node); >> expires = ktime_sub(hrtimer_get_expires(timer), >>base->offset); >> if (expires.tv64 < expires_next.tv64) >>@@ -1206,17 +1206,16 @@ static void __run_hrtimer(struct hrtimer >> >> static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t >>now) >> { >>- int i; >>+ struct hrtimer_clock_base *base = cpu_base->clock_base; >>+ unsigned int active = cpu_base->active_bases; >> >>- for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) { >>- struct hrtimer_clock_base *base; >>+ for (; active; base++, active >>= 1) { >> struct timerqueue_node *node; >> ktime_t basenow; >> >>- if (!(cpu_base->active_bases & (1 << i))) >>+ if (!(active & 0x01)) >> continue; >> >>- base = cpu_base->clock_base + i; >> basenow = ktime_add(now, base->offset); >> >> while ((node = timerqueue_getnext(&base->active))) { >>