Re: [PATCH v4 2/6] perf: Enqueue SIGTRAP always via task_work.
From: Frederic Weisbecker
Date: Fri Nov 08 2024 - 17:26:47 EST
Le Fri, Nov 08, 2024 at 08:08:36PM +0100, Oleg Nesterov a écrit :
> Sorry, currently I don't have time to even read the emails from lkml.
>
> Plus I wasn't cc'ed so I don't understand the intent at all, but ...
>
> On 11/08, Frederic Weisbecker wrote:
> >
> > > @@ -232,13 +222,24 @@ void task_work_run(void)
> > > * But it can remove another entry from the ->next list.
> > > */
> > > raw_spin_lock_irq(&task->pi_lock);
> > > + do {
> > > + head = NULL;
> > > + if (work) {
> > > + head = READ_ONCE(work->next);
> > > + } else {
> > > + if (task->flags & PF_EXITING)
> > > + head = &work_exited;
> > > + else
> > > + break;
> > > + }
> > > + } while (!try_cmpxchg(&task->task_works, &work, head));
> > > raw_spin_unlock_irq(&task->pi_lock);
> >
> > And having more than one task work should be sufficiently rare
> > that we don't care about doing the locking + cmpxchg() for each
> > of them pending.
>
> Please see
> https://lore.kernel.org/all/1440816150.8932.123.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> and the whole thread.
>
> I don't think raw_spin_lock_irq + cmpxchg for each work is a good
> idea, but quite possibly I misunderstood this change.
I did not realize there could be gazillion files released in a row. So there
could be noticeable performance issues I guess...
Thanks.
>
> Oleg.
>