From: Thomas Gleixner <tglx@linutronix.de>
To: Yu Liao <liaoyu15@huawei.com>, linux-kernel@vger.kernel.org
Cc: liwei391@huawei.com, wangxiongfeng2@huawei.com,
frederic@kernel.org, mingo@kernel.org
Subject: Re: [PATCH] tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled
Date: Wed, 24 Jan 2024 20:18:16 +0100 [thread overview]
Message-ID: <87y1cek0av.ffs@tglx> (raw)
In-Reply-To: <20231218025844.55675-1-liaoyu15@huawei.com>
On Mon, Dec 18 2023 at 10:58, Yu Liao wrote:
> static int bc_set_next(ktime_t expires, struct clock_event_device *bc)
> {
> + ktime_t next_event = this_cpu_ptr(&tick_cpu_device)->evtdev->next_event;
> +
> /*
> - * This is called either from enter/exit idle code or from the
> - * broadcast handler. In all cases tick_broadcast_lock is held.
> - *
> + * This can be called from CPU offline operation to move broadcast
> + * assignment. If tick_broadcast_force_mask is set, the CPU local
> + * timer device may be disabled. And hrtimer_reprogram() will not
> + * called if the timer is not the first expiring timer. Reprogram
> + * the cpu local timer device to ensure we can take over the
> + * broadcast duty.
> + */
> + if (tick_check_broadcast_expired() && expires >= next_event)
> + tick_program_event(next_event, 1);
I'm not really enthused about another conditional here and that
condition is more than obscure.
The problem is that the local clockevent might be shut down, right?
So checking for that state is the right thing to do and the proper place
is in hotplug_cpu__broadcast_tick_pull(), no?
Thanks,
tglx
next prev parent reply other threads:[~2024-01-24 19:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 2:58 [PATCH] tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled Yu Liao
2024-01-12 7:40 ` Yu Liao
2024-01-12 15:34 ` Thomas Gleixner
2024-01-24 19:18 ` Thomas Gleixner [this message]
2024-07-11 13:10 ` Yu Liao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y1cek0av.ffs@tglx \
--to=tglx@linutronix.de \
--cc=frederic@kernel.org \
--cc=liaoyu15@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liwei391@huawei.com \
--cc=mingo@kernel.org \
--cc=wangxiongfeng2@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox