From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>,
Anthony PERARD <anthony.perard@vates.tech>,
Michal Orzel <michal.orzel@amd.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 3/6] xen/softirq: Rework arch_skip_send_event_check() into arch_pend_softirq()
Date: Fri, 4 Jul 2025 09:55:42 +0200 [thread overview]
Message-ID: <aGeI_k1H3oju26hf@macbook.local> (raw)
In-Reply-To: <86dde581-40ad-405e-8d98-0b4485529581@suse.com>
On Fri, Jul 04, 2025 at 09:23:29AM +0200, Jan Beulich wrote:
> On 03.07.2025 18:21, Roger Pau Monné wrote:
> > On Wed, Jul 02, 2025 at 03:41:18PM +0100, Andrew Cooper wrote:
> >> --- a/xen/include/xen/softirq.h
> >> +++ b/xen/include/xen/softirq.h
> >> @@ -23,6 +23,22 @@ enum {
> >>
> >> #define NR_SOFTIRQS (NR_COMMON_SOFTIRQS + NR_ARCH_SOFTIRQS)
> >>
> >> +/*
> >> + * Ensure softirq @nr is pending on @cpu. Return true if an IPI can be
> >> + * skipped, false if the IPI cannot be skipped.
> >> + */
> >> +#ifndef arch_pend_softirq
> >> +static always_inline bool arch_pend_softirq(unsigned int nr, unsigned int cpu)
> >
> > Nit: I would maybe it arch_set_softirq(), I find `pend` not that clear
> > (I would rather fully spell `pending` instead).
>
> I, too, did wonder about the naming here. But using "pending" as you suggest
> has the effect of giving the function a name we would normally associate with
> a predicate ("Is it pending?"), whereas here the function is used to _mark_ a
> softirq as pending. Hence in the end I didn't comment at all; I'd be fine
> with "set", but I'm also okay with "pend".
It's a set and check kind of function, so I don't care much. Just
found the pend a bit too short, I don't think we usually abbreviate
pending to pend. In fact we use pend in more than one variable name
to store the end of a physical memory region.
Thanks, Roger.
next prev parent reply other threads:[~2025-07-04 7:55 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 14:41 [PATCH 0/6] x86/idle: Multiple MWAIT fixes Andrew Cooper
2025-07-02 14:41 ` [PATCH 1/6] x86/idle: Remove broken MWAIT implementation Andrew Cooper
2025-07-03 16:01 ` Roger Pau Monné
2025-07-03 16:19 ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 2/6] x86/idle: Convert force_mwait_ipi_wakeup to X86_BUG_MONITOR Andrew Cooper
2025-07-02 14:41 ` [PATCH 3/6] xen/softirq: Rework arch_skip_send_event_check() into arch_pend_softirq() Andrew Cooper
2025-07-03 8:11 ` Jan Beulich
2025-07-03 10:36 ` Andrew Cooper
2025-07-03 11:24 ` Jan Beulich
2025-07-03 16:21 ` Roger Pau Monné
2025-07-04 7:23 ` Jan Beulich
2025-07-04 7:55 ` Roger Pau Monné [this message]
2025-07-04 8:25 ` Jan Beulich
2025-07-04 16:00 ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 4/6] x86/idle: Implement a new MWAIT IPI-elision algorithm Andrew Cooper
2025-07-03 9:01 ` Jan Beulich
2025-07-03 11:59 ` Andrew Cooper
2025-07-03 14:07 ` Jan Beulich
2025-07-03 17:29 ` Andrew Cooper
2025-07-03 16:36 ` Roger Pau Monné
2025-07-03 17:48 ` Andrew Cooper
2025-07-04 7:24 ` Roger Pau Monné
2025-07-04 16:13 ` Andrew Cooper
2025-07-04 7:52 ` Roger Pau Monné
2025-07-04 16:14 ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 5/6] x86/idle: Drop incorrect smp_mb() in mwait_idle_with_hints() Andrew Cooper
2025-07-03 9:24 ` Jan Beulich
2025-07-03 12:37 ` Andrew Cooper
2025-07-03 13:30 ` Jan Beulich
2025-07-04 15:45 ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 6/6] x86/idle: Fix buggy "x86/mwait-idle: enable interrupts before C1 on Xeons" Andrew Cooper
2025-07-03 9:35 ` Jan Beulich
2025-07-03 9:43 ` Jan Beulich
2025-07-03 12:10 ` Andrew Cooper
2025-07-03 13:11 ` 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=aGeI_k1H3oju26hf@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.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 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.