From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753434AbbDBOQo (ORCPT ); Thu, 2 Apr 2015 10:16:44 -0400 Received: from casper.infradead.org ([85.118.1.10]:36705 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752497AbbDBOQm (ORCPT ); Thu, 2 Apr 2015 10:16:42 -0400 Date: Thu, 2 Apr 2015 16:16:33 +0200 From: Peter Zijlstra To: Viresh Kumar Cc: Thomas Gleixner , Ingo Molnar , Linaro Kernel Mailman List , Linux Kernel Mailing List Subject: Re: [PATCH 1/2] hrtimer: update '->active_bases' before calling hrtimer_force_reprogram() Message-ID: <20150402141633.GC23123@twins.programming.kicks-ass.net> References: <20150402134713.GB23123@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 02, 2015 at 07:23:31PM +0530, Viresh Kumar wrote: > On 2 April 2015 at 19:17, Peter Zijlstra wrote: > > On Thu, Apr 02, 2015 at 04:21:21PM +0530, Viresh Kumar wrote: > >> 'active_bases' indicates which clock-base have active timers. While it > >> is updated (almost) correctly, it is hardly used. Next commit will start > >> using it to make code more efficient, but before that we need to fix a > >> problem. > >> > >> While removing hrtimers, in __remove_hrtimer(): > >> - We first remove the hrtimer from the queue. > >> - Then reprogram clockevent device if required > >> (hrtimer_force_reprogram()). > >> - And then finally clear 'active_bases', if no more timers are pending > >> on the current clock base (from which we are removing the hrtimer). > >> > >> hrtimer_force_reprogram() needs to loop over all active clock bases to > >> find the next expiry event, and while doing so it will use > >> 'active_bases' (after next commit). And it will find the current base > >> active, as we haven't cleared it until now, even if current clock base > >> has no more hrtimers queued. > >> > >> To fix this issue, clear active_bases before calling > >> hrtimer_force_reprogram(). > > > > This is a small inefficiency right? Not an actual bug or anything. > > So, what's explained in this patch is a BUG, which isn't harming us today. So then I'm not seeing how its a bug. Sure __hrtimer_get_next_event() will iterate all the bases again, and it will not skip the just empty one. But I don't see how that is anything but an inefficiency. By virtue of the base being empty it cannot find an event there, so its a pointless check. What am I missing?