From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934297AbbDIJSw (ORCPT ); Thu, 9 Apr 2015 05:18:52 -0400 Received: from mail-wg0-f45.google.com ([74.125.82.45]:34927 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932588AbbDIJSl (ORCPT ); Thu, 9 Apr 2015 05:18:41 -0400 Date: Thu, 9 Apr 2015 11:18:36 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Viresh Kumar , Ingo Molnar , Peter Zijlstra , linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org, Preeti U Murthy Subject: Re: [PATCH] hrtimer: Replace cpu_base->active_bases with a direct check of the active list Message-ID: <20150409091836.GA11494@gmail.com> References: <20150409062841.GB14259@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Gleixner wrote: > On Thu, 9 Apr 2015, Ingo Molnar wrote: > > Btw., does cpu_base->active_bases even make sense? hrtimer bases are > > fundamentally percpu, and to check whether there are any pending > > timers is a very simple check: > > > > base->active->next != NULL > > > > So I'd rather suggest taking a direct look at the head, instead of > > calculating bit positions, masks, etc. > > > > Furthermore, we never actually use cpu_base->active_bases as a > > 'summary' value (which is the main point of bitmasks in general), > > so I'd remove that complication altogether. > > > > This would speed up various hrtimer primitives like > > hrtimer_remove()/add and simplify the code. It would be a net code > > shrink as well. > > Well. You trade a bit more code against touching cache lines to > figure out whether the clock base has active timers or not. So for a > lot of scenarios where only clock monotonic is used you touch 3 > cache lines for nothing. In the (typical) case it will touch one extra cacheline - and removes a fair bit of complexity which 80 bytes (that touches two cachelines): 7502 427 0 7929 1ef9 hrtimer.o.before 7422 427 0 7849 1ea9 hrtimer.o.after So even if we were to optimize for cache footprint (which isn't the only factor we optimize for)it looks like a win-win scenario to me, even if you ignore the speedup and the simpler code structure... Ok? > I'm about to send out a patch which actually makes better use of the > active_bases field without creating a code size explosion. So please lets do this series first - it achieves the same thing, with less cache used and faster code. Thanks, Ingo