From: Adrian Hunter <adrian.hunter@intel.com>
To: Julian Vetter <julian@outer-limits.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: <xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>,
"Juergen Gross" <jgross@suse.com>,
Thomas Gleixner <tglx@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Jiayuan Chen <jiayuan.chen@linux.dev>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org>
Subject: Re: [PATCH 0/2] Re-raise irq_work lost during Xen suspend
Date: Mon, 9 Nov 2026 12:56:24 +0200 [thread overview]
Message-ID: <d52e1070-be5d-4367-b9d2-d79bbe9a4c8e@intel.com> (raw)
In-Reply-To: <1fb98f79-183c-4144-aaac-45a437ff2d32@outer-limits.org>
On 09/11/2026 12:16, Julian Vetter wrote:
> On 11/6/26 4:39 PM, Sebastian Andrzej Siewior wrote:
>>
>> Looking at #1, you could probably limit it to a nop on
>> !arch_irq_work_has_interrupt(). The tick should not be disabled if
>> irq_work_needs_cpu() returns true (you don't add anything).
>>
>
> Yes, right, the lazy part is pointless.
>
>> And lazy items get handled via irq_work_tick() anyway. This make me
>> think if it gets any easier if we handle both in irq_work_tick(). On x86
>> raised_list is evaluated anyway so by dropping
>> arch_irq_work_has_interrupt() we would avoid the APIC check and handle
>> list in this rare case. If the IRQ-work is working then the list remains
>> empty.
>>
>
> This is maybe a cleaner solution, it needs no APIC access and no call site in the suspend paths. But irq_work_needs_cpu() would need the same change, otherwise in a CONFIG_NOHZ=y setting an idle CPU would still sit on the work until it leaves idle and re-enables the timer tick, no? I will test this.
A fix for stable is needed, so need to check that there is no
irq_work that would have a problem running in the tick context.
prev parent reply other threads:[~2026-11-09 10:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1793977074.8631fc262581453bbf619ec5b2062170.1a1b15dc430000403d@vates.tech>
2026-11-06 15:36 ` Sebastian Andrzej Siewior
2026-11-09 10:16 ` Julian Vetter
2026-11-09 10:56 ` Adrian Hunter [this message]
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=d52e1070-be5d-4367-b9d2-d79bbe9a4c8e@intel.com \
--to=adrian.hunter@intel.com \
--cc=bigeasy@linutronix.de \
--cc=jgross@suse.com \
--cc=jiayuan.chen@linux.dev \
--cc=julian@outer-limits.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=peterz@infradead.org \
--cc=sstabellini@kernel.org \
--cc=tglx@kernel.org \
--cc=vineeth@bitbyteword.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®