[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b3bbe8f20e14a7b91dc85737ecb99c0@AcuMS.aculab.com>
Date: Wed, 14 Apr 2021 15:59:12 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Peter Zijlstra' <peterz@...radead.org>,
Guo Ren <guoren@...nel.org>
CC: Christoph Müllner <christophm30@...il.com>,
"Palmer Dabbelt" <palmer@...belt.com>,
Anup Patel <anup@...infault.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Guo Ren <guoren@...ux.alibaba.com>,
"Catalin Marinas" <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
"Arnd Bergmann" <arnd@...db.de>, Jonas Bonn <jonas@...thpole.se>,
"Stefan Kristiansson" <stefan.kristiansson@...nalahti.fi>,
Stafford Horne <shorne@...il.com>
Subject: RE: [RFC][PATCH] locking: Generic ticket-lock
From: Peter Zijlstra
> Sent: 14 April 2021 13:56
>
> > I've tested it on csky SMP*4 hw (860) & riscv SMP*4 hw (c910) and it's okay.
>
> W00t :-)
>
> > Hope you can keep
> > typedef struct {
> > union {
> > atomic_t lock;
> > struct __raw_tickets {
> > #ifdef __BIG_ENDIAN
> > u16 next;
> > u16 owner;
> > #else
> > u16 owner;
> > u16 next;
> > #endif
> > } tickets;
> > };
> > } arch_spinlock_t;
> >
> > Using owner & next is much more readable.
>
> That almost doubles the line-count of the thing ;-)
And relies on the compiler not ever spilling it to stack.
Which it is much more likely to do that for the version
that uses shifts.
Have you checked what happens with -O0 ?
I don't think that is banned by the build system.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists