On Thu, Oct 21, 2021 at 03:49:51PM +0200, Arnd Bergmann wrote: > On Thu, Oct 21, 2021 at 3:05 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > Therefore provide ticket locks, which depend on a single atomic > > operation (fetch_add) while still providing fairness. > > Nice! > > Aside from the qspinlock vs ticket-lock question, can you describe the > tradeoffs between this generic ticket lock and a custom implementation > in architecture code? Should we convert most architectures over > to the generic code in the long run, or is there something they > can usually do better with an inline asm based ticket lock I think for a load-store arch this thing should generate pretty close to optimal code. x86 can do ticket_unlock() slightly better using a single INCW (or ADDW 1) on the owner subword, where this implementation will to separate load-add-store instructions. If that is actually measurable is something else entirely. > or a trivial test-and-set? If your SMP arch is halfway sane (no fwd progress issues etc..) then ticket should behave well and avoid the starvation/variablilty of TaS lock. The big exception there is virtualized architectures, ticket is absolutely horrendous for 'guests' (any fair lock is for that matter).
