From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966103AbdIZMOx (ORCPT ); Tue, 26 Sep 2017 08:14:53 -0400 Received: from merlin.infradead.org ([205.233.59.134]:54484 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934836AbdIZMOv (ORCPT ); Tue, 26 Sep 2017 08:14:51 -0400 Date: Tue, 26 Sep 2017 14:14:35 +0200 From: Peter Zijlstra To: Anna-Maria Gleixner 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 Message-ID: <20170926121435.sr35j6anagg5ckof@hirez.programming.kicks-ass.net> References: <20170831105725.809317030@linutronix.de> <20170831105826.365542256@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170831105826.365542256@linutronix.de> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? So we do this to unconditionally track expire_next, such that we can (later) use hrtimer_check_target()?