All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Mete Durlu <meted@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Juergen Christ <jchrist@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 11/11] s390/percpu: Rework to simplify percpu_entry() and percpu_exit()
Date: Mon, 21 Sep 2026 10:55:18 +0100	[thread overview]
Message-ID: <20260921105518.26f3dcf7@pumpkin> (raw)
In-Reply-To: <20260921084005.4022574-12-hca@linux.ibm.com>

On Mon, 21 Sep 2026 10:40:05 +0200
Heiko Carstens <hca@linux.ibm.com> wrote:

> The percpu code section functionality uses a rather complex method to
> figure out if the register, which contains the address of the current
> cpu's percpu variable, needs to be adjusted.
> 
> If an interrupt happens within a percpu code section (indicated by a
> lowcore field), the instruction at the interrupted location is
> checked. If it is not a specific AG instruction, the register needs to
> be updated. This mechanism needs to take kprobes into account, and
> enforces a specific instruction ordering.
> 
> Mark Rutland provided a different solution for arm64 [1] which comes
> without such limitations, but requires to use one more instruction, and
> two more registers. Given that this simplifies percpu_entry() and
> percpu_exit() it seems to be worth to go that route.
> 
> Change s390 to implement a similar approach. This requires to encode
> three register numbers into the "percpu_register" field, which is used
> to indicate if a percpu code section is executed.
> 
> The used mviy instruction can write only one byte, which allows to
> encode only two register numbers. Use a register pair for the inline
> assemblies, and only encode the even register number of the register
> pair to work around this.
> 
> The generated code changes like this for e.g. a simple this_cpu_inc():
> 
> Old:
> 
> c0 20 00 00 00 00  larl    %r2,c6 <foo+0x6> <-- load address of percpu var
> b9 04 00 32        lgr     %r3,%r2          <-- pointless copy of address
> eb 03 03 c0 00 52  mviy    960,3            <-- start of percpu code section
>                                                 - gpr 3 contains percpu var address
> e3 30 03 b8 00 08  ag      %r3,952          <-- add percpu offset
> eb 01 30 00 00 7a  agsi    0(%r3),1         <-- atomic inc
> eb 00 03 c0 00 52  mviy    960,0            <-- end of percpu code section
> 
> New:
> 
> c0 10 00 00 00 00  larl    %r1,c6 <foo+0x6> <-- load address of percpu var
> eb 21 03 c0 00 52  mviy    960,33           <-- start of percpu code section
>                                                 33 == 0x21:
> 						- gpr 1 contains percpu var address
> 						- gpr 2 used for percpu offset
>   					        - gpr 2+1 == 3 used for current cpu's percpu var address
> e3 20 03 b8 00 04  lg      %r2,952          <-- load percpu offset
> 41 32 10 00        la      %r3,0(%r2,%r1)   <-- generate current cpu's percpu var address
> eb 01 30 00 00 7a  agsi    0(%r3),1         <-- atomic inc
> eb 00 03 c0 00 52  mviy    960,0            <-- end of percpu code section
> 
> In the above "new" code example 33 (0x21) is used as indicator value to
> mark that a percpu code section is executed. This value implies that
> registers 2 and 3 will (only) hold the percpu offset and the current
> cpu's percpu var address. Those registers will be updated by
> percpu_exit() if the process was migrated to a different cpu to contain
> the percpu offset and percpu var address of the new cpu.
> 
> Note that because of the pointless lgr instruction in the "old" code
> example the two code sequences have identical size, and it looks like
> only one more register is used. However this is because of suboptimal
> gcc code generation.

In both cases the register dependency chain length is 3 (ignoring the
pointless lgr) so the execution time is likely to be the same.

...
> +	regpcp = FIELD_GET(PCPU_REG_PCP, regval);
> +	regoff = FIELD_GET(PCPU_REG_OFF, regval);
...
> +#define PCPU_REG_PCP_SHIFT		0
> +#define PCPU_REG_PCP			GENMASK(3, 0)
> +#define PCPU_REG_OFF_SHIFT		4
> +#define PCPU_REG_OFF			GENMASK(7, 4)
...
> +#define __PCPU_CALC_REGVAL(regpcp, regoff)					\
> +	"(" regpcp " << " __stringify(PCPU_REG_PCP_SHIFT) ") |"			\
> +	"(" regoff " << " __stringify(PCPU_REG_OFF_SHIFT) ")"

I'm not a big fan of GENMASK() + FIELD_GET() and I'm not at all sure it
really helps here.
Maybe:
	regpcp = (regval >> PCPU_REG_PCP_SHIFT) & 15;
	regoff = (regval >> PCPU_REG_OFF_SHIFT) & 15;
Which at least uses the same constants for encode and decode.

But I might just comment that the pcp register is in the high nibble
(twice) and remove the 'crud'.
#define __PCPU_CALC_REGVAL(regpcp, regoff) "(" regpcp " << 4 ) | " regoff
	regpcp = regval >> 4;
	regoff = regval & 15;

David

  parent reply	other threads:[~2026-09-21  9:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21  8:39 [PATCH v3 00/11] s390: More this_cpu_*() changes Heiko Carstens
2026-09-21  8:39 ` [PATCH v3 01/11] s390/percpu: Fix comment typo Heiko Carstens
2026-09-21  8:41   ` sashiko-bot
2026-09-21  8:39 ` [PATCH v3 02/11] s390/percpu: Add sanity check to GEN_MVIY macro Heiko Carstens
2026-09-21  8:44   ` sashiko-bot
2026-09-21  8:39 ` [PATCH v3 03/11] s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS Heiko Carstens
2026-09-21  8:45   ` sashiko-bot
2026-09-21  8:39 ` [PATCH v3 04/11] s390/percpu: Let MVIY_PERCPU() calculate alternative displacement Heiko Carstens
2026-09-21  8:45   ` sashiko-bot
2026-09-21  8:39 ` [PATCH v3 05/11] s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines Heiko Carstens
2026-09-21  8:45   ` sashiko-bot
2026-09-21  8:40 ` [PATCH v3 06/11] s390/percpu: Rename inline assembly symbolic names Heiko Carstens
2026-09-21  8:44   ` sashiko-bot
2026-09-21  8:40 ` [PATCH v3 07/11] s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies Heiko Carstens
2026-09-21  8:45   ` sashiko-bot
2026-09-21  8:40 ` [PATCH v3 08/11] s390/percpu: Use percpu code section for this_cpu_cmpxchg128() Heiko Carstens
2026-09-21  8:46   ` sashiko-bot
2026-09-21  8:40 ` [PATCH v3 09/11] s390/percpu: Use percpu code section for this_cpu_xchg() Heiko Carstens
2026-09-21  8:45   ` sashiko-bot
2026-09-21  8:40 ` [PATCH v3 10/11] s390/percpu: Use percpu code section for this_cpu_cmpxchg() Heiko Carstens
2026-09-21  8:52   ` sashiko-bot
2026-09-21  8:40 ` [PATCH v3 11/11] s390/percpu: Rework to simplify percpu_entry() and percpu_exit() Heiko Carstens
2026-09-21  8:52   ` sashiko-bot
2026-09-21  9:55   ` David Laight [this message]
2026-09-21 10:07     ` Mark Rutland
2026-09-21 10:17       ` Heiko Carstens
2026-09-21  9:15 ` [PATCH v3 00/11] s390: More this_cpu_*() changes Heiko Carstens

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=20260921105518.26f3dcf7@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=jchrist@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=meted@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=svens@linux.ibm.com \
    /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.