From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752044AbdI1IJh (ORCPT ); Thu, 28 Sep 2017 04:09:37 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55306 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751371AbdI1IJc (ORCPT ); Thu, 28 Sep 2017 04:09:32 -0400 Date: Thu, 28 Sep 2017 10:09:28 +0200 (CEST) From: Anna-Maria Gleixner To: Peter Zijlstra cc: LKML , Ingo Molnar , Christoph Hellwig , keescook@chromium.org, John Stultz , Thomas Gleixner Subject: Re: [PATCH 10/25] hrtimer: Make handling of hrtimer reprogramming and enqueuing not conditional In-Reply-To: <20170926121435.sr35j6anagg5ckof@hirez.programming.kicks-ass.net> Message-ID: References: <20170831105725.809317030@linutronix.de> <20170831105826.365542256@linutronix.de> <20170926121435.sr35j6anagg5ckof@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Sep 2017, Peter Zijlstra wrote: > On Thu, Aug 31, 2017 at 12:23:38PM -0000, Anna-Maria Gleixner wrote: > > The hrtimer_reprogramming, remote timer enqueuing and handling of the > > hrtimer_cpu_base struct member expires_next depend on the active high > > resolution timers. This makes the code harder to understand. > > > > To simplify the code, the hrtimer reprogramming is now executed > > independently except for the real reprogramming part. The expires_next > > stores now the first enqueued timer. Due to the adaption of the > > check_target function, remote enqueuing is now only possible when the > > expiry time is after the currently first expiry time independent of the > > active high resolution timers. > > Sorry, very hard to follow. What? I'm sorry, I have to rework the commit messages... > > So we do this to unconditionally track expire_next, such that we can > (later) use hrtimer_check_target()? > The main goal of this patch and the three patches before in the series is to reduce the conditional code. I tried to split it into pieces... next_timer stores the pointer to the first expiring timer. In __remove_hrtimer() next_timer is compared to the removed timer; if the pointers match then the hardware needs to be reprogrammed. This is done to avoid the extra interrupt which was armed for the removed timer. So its a HIGH_RES only functionality. For the softirq mode we need that pointer to have access to the first expiring timer unconditionally. expires_next stores the next event armed in hardware. That's used to check whether a timer can be enqueued remotely. If the new timer is expiring before expires_next, then remote enqueue is not possible as we cannot access the remote timer hardware to reprogram it. This is currently conditional for the HIGH_RES case, but there is no reason to make this conditional. So I made HIGH_RES and !HIGH_RES behave the same way just to further reduce the ifdef and conditional zoo. Anna-Maria