> -----Original Message----- > From: Jerin Jacob Kollanukkaran <[email protected]> > Sent: Friday, December 28, 2018 12:39 PM > To: [email protected] > Cc: [email protected]; [email protected]; nd > <[email protected]>; [email protected]; [email protected]; > [email protected]; Joyce Kong (Arm Technology China) <[email protected]>; > [email protected]; Honnappa Nagarahalli > <[email protected]>; Gavin Hu (Arm Technology China) > <[email protected]> > Subject: Re: [EXT] [PATCH v3 6/6] spinlock: ticket based to improve fairness > > On Thu, 2018-12-27 at 15:41 -0800, Stephen Hemminger wrote: > > On Thu, 27 Dec 2018 12:08:26 +0000 > > Jerin Jacob Kollanukkaran <[email protected]> wrote: > > > > > On Thu, 2018-12-27 at 10:05 +0000, Gavin Hu (Arm Technology China) > > > wrote: > > > > > -----Original Message----- > > > > > From: Jerin Jacob Kollanukkaran <[email protected]> > > > > > Sent: Thursday, December 27, 2018 2:58 PM > > > > > To: Gavin Hu (Arm Technology China) <[email protected]>; > > > > > [email protected] > > > > > Cc: [email protected]; [email protected]; nd > > > > > <[email protected]>; [email protected]; [email protected]; > > > > > Joyce > > > > > Kong (Arm Technology China) <[email protected]>; > > > > > [email protected]; [email protected]; Honnappa > > > > > Nagarahalli <[email protected]> > > > > > Subject: Re: [EXT] [PATCH v3 6/6] spinlock: ticket based to > > > > > improve > > > > > fairness > > > > > > > > > > On Thu, 2018-12-27 at 12:13 +0800, Gavin Hu wrote: > > > > > > ----------------------------------------------------------- > > > > > > ---- > > > > > > ---- > > > > > > --- > > > > > > From: Joyce Kong <[email protected]> > > > > > > > > > > > > The old implementation is unfair, some threads may take locks > > > > > > aggressively > > > > > > > > > > I think, one issue here is x86 and ppc follows traditional > > > > > spinlock > > > > > and > > > > > arm64 will be following ticket lock for spinlock > > > > > implementation. > > > > > This would change application behaviour on arm64 compared to > > > > > x86 > > > > > and > > > > > ppc. > > > > > > > > > > How about having a separate API for ticket lock? That would > > > > > give, > > > > > # application choice to use the locking strategy > > > > > # application behaviour will be same across all arch. > > > > > > > > Ok, will do in v4 to have a new named rte_ticket_spinlock API. > > > > > > I would prefer rte_ticketlock_[lock/unlock/trylock/is_locked] name > > > instead of rte_ticket_spinlock_lock etc to reduce the length of the > > > API. > > > > NAK to adding new API for this. > > > > I want the best possible locks for all applications and all > > architectures. > > These should be called spinlock so there is no requirement for > > application > > to change to get better performance. Why not just implement the best > > algorithm > > across the board. Yes, this means collaboration or working on the > > other guys > > architecture. > > Then 6/6 patch needs to put on hold if every arch needs to make ticket > lock as default spinlock lock strategy. > > How about following to make forward progress: > 1) Introduce rte_ticketlock_[lock/unlock/trylock/is_locked] API now as > experimental with default implementation > 2) Provide a time line to switch every arch for optimized ticketlock > implementation if needed. > 3) Switch rte_ticketlock_ as rte_spinlock_ API. > 4) Keep old version of spinlock as new API if some application does not > need fairness between threads at the cost of light weight spinlock > implementation.
We will rework the patches following this proposal, and let's switch over at some point of later. > I don't want arm64 to behave differently than other arch(s). This is the generic implementation, x86 and ppc can choose also by setting CONFIG_RTE_FORCE_INTRINSICS=y in the config file. The arch specific implementation is instruction level based, arm will implement this also, they are not ticket based. >
