All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3 for-4.21 1/9] x86/HPET: deal with unused channels
Date: Fri, 24 Oct 2025 14:16:53 +0200	[thread overview]
Message-ID: <aPtuNclNlRd7mx2E@Mac.lan> (raw)
In-Reply-To: <86001bc5-de05-4a5b-9683-54d09c5fa8a8@suse.com>

On Thu, Oct 23, 2025 at 05:49:57PM +0200, Jan Beulich wrote:
> Keeping channels enabled when they're unused is only causing problems:
> Extra interrupts harm performance, and extra nested interrupts could even
> have caused worse problems. However, on all Intel hardware I looked at
> closely, a 0->1 transition of the enable bit causes an immediate IRQ.
> Hence disabling channels isn't a good idea there. Set a "long" timeout
> instead.
> 
> Along with that also "clear" the channel's "next event", for it to be
> properly written by whatever the next user is going to want (possibly
> avoiding too early an IRQ).
> 
> Further, along the same lines, don't enable channels early when starting
> up an IRQ. This doesn't need to happen earlier than from
> set_channel_irq_affinity() (once a channel goes into use the very first
> time). This eliminates a single instance of
> 
> (XEN) [VT-D]INTR-REMAP: Request device [0000:00:1f.0] fault index 0
> (XEN) [VT-D]INTR-REMAP: reason 25 - Blocked a compatibility format interrupt request
> 
> during boot. (Why exactly there's only one instance, when we use multiple
> counters and hence multiple IRQs, I can't tell. My understanding would be
> that this was due to __hpet_setup_msi_irq() being called only after
> request_irq() [and hence the .startup handler], yet that should have
> affected all channels.)
> 
> Fixes: 3ba523ff957c ("CPUIDLE: enable MSI capable HPET for timer broadcast")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


  reply	other threads:[~2025-10-24 12:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-23 15:48 [PATCH v3 for-4.21 0/9] x86/HPET: broadcast IRQ and other improvements Jan Beulich
2025-10-23 15:49 ` [PATCH v3 for-4.21 1/9] x86/HPET: deal with unused channels Jan Beulich
2025-10-24 12:16   ` Roger Pau Monné [this message]
2025-10-23 15:50 ` [PATCH v3 for-4.21 2/9] x86/HPET: use single, global, low-priority vector for broadcast IRQ Jan Beulich
2025-10-24 13:24   ` Roger Pau Monné
2025-10-27 10:23     ` Jan Beulich
2025-10-27 11:33       ` Roger Pau Monné
2025-10-27 11:53         ` Jan Beulich
2025-10-27 11:57           ` Jan Beulich
2025-10-27 11:57           ` Roger Pau Monné
2025-10-23 15:51 ` [PATCH v3 for-4.21 3/9] x86/HPET: replace handle_hpet_broadcast()'s on-stack cpumask_t Jan Beulich
2025-10-27 12:25   ` Jan Beulich
2025-10-27 15:20     ` Oleksii Kurochko
2025-10-23 15:51 ` [PATCH v3 4/9] x86/HPET: avoid indirect call to event handler Jan Beulich
2025-10-23 15:51 ` [PATCH v3 5/9] x86/HPET: make another channel flags update atomic Jan Beulich
2025-10-23 15:52 ` [PATCH v3 6/9] x86/HPET: move legacy tick IRQ count adjustment Jan Beulich
2025-10-23 15:52 ` [PATCH v3 7/9] x86/HPET: reduce hpet_next_event() call sites Jan Beulich
2025-10-23 15:52 ` [PATCH v3 8/9] x86/HPET: drop "long timeout" handling from reprogram_hpet_evt_channel() Jan Beulich
2025-10-23 15:53 ` [PATCH v3 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=aPtuNclNlRd7mx2E@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.