From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>
Subject: Re: [PATCH v2 for-4.21 8/9] x86/HPET: don't use hardcoded 0 for "long timeout"
Date: Tue, 21 Oct 2025 15:21:25 +0100 [thread overview]
Message-ID: <aPeW5RZgFKKF15hw@Mac.lan> (raw)
In-Reply-To: <2e140536-6e24-4de7-a5f6-0c0e19951f13@suse.com>
On Mon, Oct 20, 2025 at 01:21:18PM +0200, Jan Beulich wrote:
> With 32-bit counters, writing 0 means on average half the wrapping period
> until an interrupt would be raised. Yet of course in extreme cases an
> interrupt would be raised almost right away. Write the present counter
> value instead, to make the timeout predicatbly a full wrapping period.
>
> Fixes: e862b83e8433 ("CPUIDLE: Avoid remnant HPET intr while force hpetbroadcast")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Maybe I'm missing a path, but are there any callers that still pass
STIME_MAX to reprogram_hpet_evt_channel()?
hpet_broadcast_exit() no longer explicitly passes STIME_MAX like it
did in e862b83e8433, and then the per-cpu timer_deadline variable is
not set to STIME_MAX either in timer_softirq_action().
Thanks, Roger.
next prev parent reply other threads:[~2025-10-21 14:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 11:16 [PATCH v2 for-4.21 0/9] x86/HPET: broadcast IRQ and other improvements Jan Beulich
2025-10-20 11:18 ` [PATCH v2 for-4.21 1/9] x86/HPET: disable unused channels Jan Beulich
2025-10-23 14:51 ` Jan Beulich
2025-10-20 11:18 ` [PATCH v2 for-4.21 2/9] x86/HPET: use single, global, low-priority vector for broadcast IRQ Jan Beulich
2025-10-20 16:22 ` Roger Pau Monné
2025-10-21 6:42 ` Jan Beulich
2025-10-21 13:49 ` Roger Pau Monné
2025-10-22 9:21 ` Jan Beulich
2025-10-22 11:59 ` Jan Beulich
2025-10-23 8:39 ` Roger Pau Monné
2025-10-23 10:37 ` Jan Beulich
2025-10-23 12:49 ` Roger Pau Monné
2025-10-23 15:36 ` Jan Beulich
2025-10-20 11:19 ` [PATCH v2 for-4.21 3/9] x86/HPET: replace handle_hpet_broadcast()'s on-stack cpumask_t Jan Beulich
2025-10-20 11:23 ` Jan Beulich
2025-10-21 14:08 ` Roger Pau Monné
2025-10-21 14:43 ` Jan Beulich
2025-10-20 11:19 ` [PATCH v2 4/9] x86/HPET: avoid indirect call to event handler Jan Beulich
2025-10-20 11:20 ` [PATCH v2 5/9] x86/HPET: make another channel flags update atomic Jan Beulich
2025-10-20 11:20 ` [PATCH v2 6/9] x86/HPET: move legacy tick IRQ count adjustment Jan Beulich
2025-10-20 11:20 ` [PATCH v2 7/9] x86/HPET: reduce hpet_next_event() call sites Jan Beulich
2025-10-20 11:21 ` [PATCH v2 for-4.21 8/9] x86/HPET: don't use hardcoded 0 for "long timeout" Jan Beulich
2025-10-20 11:24 ` Jan Beulich
2025-10-21 14:21 ` Roger Pau Monné [this message]
2025-10-21 14:48 ` Jan Beulich
2025-10-20 11:21 ` [PATCH v2 9/9] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() Jan Beulich
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=aPeW5RZgFKKF15hw@Mac.lan \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.