Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1739822
| 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 | 2017-09-26 14:20 +0200 |
| Message-ID | <utX0d-4FS-1@gated-at.bofh.it> (permalink) |
| References | <ukwLD-5Ay-3@gated-at.bofh.it> <ukwLG-5Ay-65@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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()?
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [PATCH 10/25] hrtimer: Make handling of hrtimer reprogramming and enqueuing not conditional Peter Zijlstra <peterz@infradead.org> - 2017-09-26 14:20 +0200 Re: [PATCH 10/25] hrtimer: Make handling of hrtimer reprogramming and enqueuing not conditional Anna-Maria Gleixner <anna-maria@linutronix.de> - 2017-09-28 10:10 +0200
csiph-web