On Wed, Nov 08, 2023 at 12:54:19AM -0800, Ankur Arora wrote: > Yosry Ahmed <yosryahmed@xxxxxxxxxx> writes: > > On Tue, Nov 7, 2023 at 11:49 PM Vlastimil Babka <vbabka@xxxxxxx> wrote: > >> On 11/8/23 02:28, Sergey Senozhatsky wrote: > >> > I'd personally prefer to have a comment explaining why we do that > >> > spin_unlock/spin_lock sequence, which may look confusing to people. > >> > >> Wonder if it would make sense to have a lock operation that does the > >> unlock/lock as a self-documenting thing, and maybe could also be optimized > >> to first check if there's a actually a need for it (because TIF_NEED_RESCHED > >> or lock is contended). > > > > +1, I was going to suggest this as well. It can be extended to other > > locking types that disable preemption as well like RCU. Something like > > spin_lock_relax() or something. > > Good point. We actually do have exactly that: cond_resched_lock(). (And > similar RW lock variants.) That's a shame; I was going to suggest calling it spin_cycle() ...
