[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r1ibewha.ffs@nanos.tec.linutronix.de>
Date: Wed, 12 May 2021 18:40:49 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
Marcelo Tosatti <mtosatti@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>,
Peter Xu <peterx@...hat.com>,
Nitesh Narayan Lal <nitesh@...hat.com>,
Alex Belits <abelits@...vell.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
John Stultz <john.stultz@...aro.org>
Subject: Re: [patch 2/8] hrtimer: Force clock_was_set() handling for the HIGHRES=n, NOHZ=y case
On Wed, May 12 2021 at 16:59, Peter Zijlstra wrote:
> On Tue, Apr 27, 2021 at 10:25:39AM +0200, Thomas Gleixner wrote:
>> void clock_was_set(void)
>> {
>> + if (!hrtimer_hres_active() && !tick_nohz_active)
>> + goto out_timerfd;
>> +
>> /* Retrigger the CPU local events everywhere */
>> on_each_cpu(retrigger_next_event, NULL, 1);
>> +
>> +out_timerfd:
>> timerfd_clock_was_set();
>> }
>
> Isn't that simpler when written like:
>
> if (hrtimer_hres_active() || tick_nohz_active())
> on_each_cpu(retrigger_next_event, NULL, 1);
>
> timerfd_clock_was_set();
>
> ?
Yes, but look at the later patches. Then we'll introduce it there. :)
Powered by blists - more mailing lists