All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH 2/2] x86: replace this_cpu() uses in mapcache_current_vcpu()
Date: Tue, 13 Oct 2026 12:15:27 +0200	[thread overview]
Message-ID: <as4Ev_8NGq-dyK-2@Mac.lan> (raw)
In-Reply-To: <f404f8fd-f1ec-476e-bc7b-b6ad8909501a@suse.com>

On Tue, Oct 13, 2026 at 11:06:27AM +0200, Jan Beulich wrote:
> We have accumulated three of them, plus a hidden similar 4th construct
> from smp_processor_id(). Latch the result of the latter into a local
> variable and use the slightly more efficient per_cpu() instead.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Oh, so that's kind of what I've suggested in the previous patch.

> ---
> A 5th such construct is "current", yet to replace that we'd need to open-
> code both it (i.e. get_current()) and then also smp_processor_id(). I
> wasn't quite sure whether that would be deemed acceptable.

See below, we can reorder and use the processor ID value stashed in
current?

> Like indicated in the earlier patch, this similarly leads to the function
> actually being inlined (and hence generated code size actually growing) in
> gcc16 debug builds. In release builds (with older gcc) the function is
> being inlined no matter what. Overall, having looked at generated code
> differences, I'm not quite sure anymore whether the earlier observed
> inefficiency with repeated this_cpu() really is much of an issue (here or
> maybe even more generally).

I think we sometimes focus too much on this kind of
micro-optimizations when the cost of the operation itself is orders of
magnitude bigger than any performance difference the optimization
might cause.

In this case I don't think the resulting code is bad or harder to
read, so I don't mind adjusting the logic.  But that's a question of
taste, if someone else has a preference for the original form I
wouldn't change it.

> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -20,7 +20,8 @@
>  
>  static inline struct vcpu *mapcache_current_vcpu(void)
>  {
> -    const struct vcpu *v = this_cpu(pgtable_vcpu);
> +    unsigned int cpu = smp_processor_id();
> +    const struct vcpu *v = per_cpu(pgtable_vcpu, cpu);
>      const struct vcpu *curr = current;

Maybe you can reorder the variables here:

const struct vcpu *curr = current;
unsigned int cpu = curr->processor;
const struct vcpu *v = per_cpu(pgtable_vcpu, cpu);

So that we avoid two smp_processor_id() calls (ie: the hidden one in
current).

Thanks, Roger.


  reply	other threads:[~2026-10-13 10:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  9:04 [PATCH 0/2] x86: mapcache_current_vcpu() adjustments Jan Beulich
2026-10-13  9:05 ` [PATCH 1/2] x86: constify local variables in mapcache_current_vcpu() Jan Beulich
2026-10-13 10:08   ` Roger Pau Monné
2026-10-13  9:06 ` [PATCH 2/2] x86: replace this_cpu() uses " Jan Beulich
2026-10-13 10:15   ` Roger Pau Monné [this message]
2026-10-13 11:52     ` 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=as4Ev_8NGq-dyK-2@Mac.lan \
    --to=roger@xenproject.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=teddy.astie@vates.tech \
    --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.