Convert pgste_get_lock() and pgste_set_unlock() to C.
There is no real reasons to keep them in assembler. Having them in C
makes them more readable and maintainable, and better instructions are
used automatically when available.
Signed-off-by: Claudio Imbrenda <[email protected]>
---
arch/s390/mm/pgtable.c | 29 ++++++++++-------------------
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 3bd2ab2a9a34..6c4523aa4fdf 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -125,32 +125,23 @@ static inline pte_t ptep_flush_lazy(struct mm_struct *mm,
static inline pgste_t pgste_get_lock(pte_t *ptep)
{
- unsigned long new = 0;
+ unsigned long value = 0;
#ifdef CONFIG_PGSTE
- unsigned long old;
-
- asm(
- " lg %0,%2\n"
- "0: lgr %1,%0\n"
- " nihh %0,0xff7f\n" /* clear PCL bit in old */
- " oihh %1,0x0080\n" /* set PCL bit in new */
- " csg %0,%1,%2\n"
- " jl 0b\n"
- : "=&d" (old), "=&d" (new), "=Q" (ptep[PTRS_PER_PTE])
- : "Q" (ptep[PTRS_PER_PTE]) : "cc", "memory");
+ unsigned long *ptr = (unsigned long *)(ptep + PTRS_PER_PTE);
+
+ do {
+ value = __atomic64_or_barrier(PGSTE_PCL_BIT, ptr);
+ } while (value & PGSTE_PCL_BIT);
+ value |= PGSTE_PCL_BIT;
#endif
- return __pgste(new);
+ return __pgste(value);
}
static inline void pgste_set_unlock(pte_t *ptep, pgste_t pgste)
{
#ifdef CONFIG_PGSTE
- asm(
- " nihh %1,0xff7f\n" /* clear PCL bit */
- " stg %1,%0\n"
- : "=Q" (ptep[PTRS_PER_PTE])
- : "d" (pgste_val(pgste)), "Q" (ptep[PTRS_PER_PTE])
- : "cc", "memory");
+ barrier();
+ WRITE_ONCE(*(unsigned long *)(ptep + PTRS_PER_PTE), pgste_val(pgste) & ~PGSTE_PCL_BIT);
#endif
}
--
2.43.0
On Tue, Dec 05, 2023 at 06:32:52PM +0100, Claudio Imbrenda wrote:
> Convert pgste_get_lock() and pgste_set_unlock() to C.
>
> There is no real reasons to keep them in assembler. Having them in C
> makes them more readable and maintainable, and better instructions are
> used automatically when available.
>
> Signed-off-by: Claudio Imbrenda <[email protected]>
> ---
> arch/s390/mm/pgtable.c | 29 ++++++++++-------------------
> 1 file changed, 10 insertions(+), 19 deletions(-)
Reviewed-by: Heiko Carstens <[email protected]>
On Tue, Dec 05, 2023 at 06:32:52PM +0100, Claudio Imbrenda wrote:
Hi Claudio,
> Convert pgste_get_lock() and pgste_set_unlock() to C.
>
> There is no real reasons to keep them in assembler. Having them in C
> makes them more readable and maintainable, and better instructions are
> used automatically when available.
>
> Signed-off-by: Claudio Imbrenda <[email protected]>
> ---
> arch/s390/mm/pgtable.c | 29 ++++++++++-------------------
> 1 file changed, 10 insertions(+), 19 deletions(-)
Acked-by: Alexander Gordeev <[email protected]>
On Tue, Dec 05, 2023 at 06:32:52PM +0100, Claudio Imbrenda wrote:
(Internal lists only)
...
> + do {
> + value = __atomic64_or_barrier(PGSTE_PCL_BIT, ptr);
Would it make sense to cpu_relax() here, e.g with a follow-up patch?
> + } while (value & PGSTE_PCL_BIT);
> + value |= PGSTE_PCL_BIT;
> #endif
> - return __pgste(new);
> + return __pgste(value);
> }
Thanks!
On Wed, Dec 06, 2023 at 10:01:18AM +0100, Alexander Gordeev wrote:
> On Tue, Dec 05, 2023 at 06:32:52PM +0100, Claudio Imbrenda wrote:
> ...
> > + do {
> > + value = __atomic64_or_barrier(PGSTE_PCL_BIT, ptr);
>
> Would it make sense to cpu_relax() here, e.g with a follow-up patch?
No, because cpu_relax() is a no-op on our architecture (besides that it
translates to barrier(); but __atomic64_or_barrier() obviously comes also
with barrier() semantics).
We used to do diag 0x44 with cpu_relax() but that caused many performance
problems, therefore we removed diag 0x44 completely from the kernel quite
some time ago.
See also commit 1b68ac8678a8 ("s390: remove last diag 0x44 caller").
On Wed, Dec 06, 2023 at 10:15:41AM +0100, Heiko Carstens wrote:
> On Wed, Dec 06, 2023 at 10:01:18AM +0100, Alexander Gordeev wrote:
> > On Tue, Dec 05, 2023 at 06:32:52PM +0100, Claudio Imbrenda wrote:
> > ...
> > > + do {
> > > + value = __atomic64_or_barrier(PGSTE_PCL_BIT, ptr);
> >
> > Would it make sense to cpu_relax() here, e.g with a follow-up patch?
>
> No, because cpu_relax() is a no-op on our architecture (besides that it
> translates to barrier(); but __atomic64_or_barrier() obviously comes also
> with barrier() semantics).
>
> We used to do diag 0x44 with cpu_relax() but that caused many performance
> problems, therefore we removed diag 0x44 completely from the kernel quite
> some time ago.
>
> See also commit 1b68ac8678a8 ("s390: remove last diag 0x44 caller").
Thanks for the clarification!
Applied.