Re: [patch V2 05/10] timer: Retrieve next expiry of pinned/non-pinned timers seperately

Peter Zijlstra
2017-04-19T07:06:07Z

On Tue, Apr 18, 2017 at 01:11:07PM +0200, Thomas Gleixner wrote:
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1472,23 +1472,27 @@ static u64 cmp_next_hrtimer_event(u64 ba
> * get_next_timer_interrupt - return the time (clock mono) of the next timer
> * @basej: base time jiffies
> * @basem: base time clock monotonic
> + * @global_evt: Pointer to store the expiry time of the next global timer
> *
> * Returns the tick aligned clock monotonic time of the next pending
> * timer or KTIME_MAX if no timer is pending.
> */
> -u64 get_next_timer_interrupt(unsigned long basej, u64 basem)
> +u64 get_next_timer_interrupt(unsigned long basej, u64 basem, u64 *global_evt)

Another tortured function signature. It seems entirely possible
@global_evt will be the next.

> +
> + /*
> + * If the local queue expires first, there is no requirement for
> + * queuing the CPU in the global expiry mechanism.

The comment doesn't make sense... (maybe at this stage)

> + */
> + if (!local_first && !global_empty)
> + *global_evt = basem + (nextevt_global - basej) * TICK_NSEC;

I was initially thinking !local_first would have to imply !global_empty,
but after going back and reading the previous patches again, I found
this was not so. Still slightly surprising.

> +
> + return cmp_next_hrtimer_event(basem, local_evt);
> }
>
> /**
>
>