[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87zgtpqrct.ffs@tglx>
Date: Tue, 10 Aug 2021 16:58:10 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Wang Qing <wangqing@...o.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Petr Mladek <pmladek@...e.com>, Wang Qing <wangqing@...o.com>,
Santosh Sivaraj <santosh@...six.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH RFC 1/2] hrtimer: support hrtimer suspend when CPU suspend
On Tue, Jun 22 2021 at 17:06, Wang Qing wrote:
> /**
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 4a66725..db34c9d
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -513,7 +513,8 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base,
>
> next = timerqueue_getnext(&base->active);
> timer = container_of(next, struct hrtimer, node);
> - if (timer == exclude) {
> + if ((timer == exclude) ||
> + (tick_nohz_tick_inidle() && timer->is_suspend)) {
Aside of being indented in unreadable ways, how is this supposed to be
correct? If the first expiring timer is excluded what prevents the next
one from being marked to stop in suspend or the other way round.
What's wrong with just canceling the offending timer before going into
suspend and rearming it on resume instead of adding a half baken magic
case for timers?
Thanks,
tglx
Powered by blists - more mailing lists