Path: csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From: Peter Zijlstra <peterz@infradead.org>
Newsgroups: linux.kernel
Subject: Re: [PATCH 10/25] hrtimer: Make handling of hrtimer reprogramming  and enqueuing not conditional
Date: Tue, 26 Sep 2017 14:20:01 +0200
Message-ID: <utX0d-4FS-1@gated-at.bofh.it>
References: <ukwLD-5Ay-3@gated-at.bofh.it> <ukwLG-5Ay-65@gated-at.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: robomod@news.nic.it
Approved: robomod@news.nic.it
Lines: 16
Organization: linux.* mail to news gateway
Xref: csiph.com linux.kernel:1739822

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()?