[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z_mQ4-7BeCCJGSIN@pavilion.home>
Date: Sat, 12 Apr 2025 00:00:03 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Michal Hocko <mhocko@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Valentin Schneider <vschneid@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org
Subject: Re: [PATCH 5/6] sched/isolation: Introduce isolated task work
Le Fri, Apr 11, 2025 at 12:25:56PM +0200, Oleg Nesterov a écrit :
> I know nothing about this code so I can't review, but let me
> ask anyway...
>
> On 04/10, Frederic Weisbecker wrote:
> >
> > +int __isolated_task_work_queue(void)
> > +{
> > + unsigned long flags;
> > + int ret;
> > +
> > + if (current->flags & PF_KTHREAD)
> > + return -EINVAL;
>
> What about PF_USER_WORKER's ? IIUC, these (in fact kernel) threads
> never return to userspace and never call task_work_run().
Ah good catch! (though I'm having a hard time finding out what this is
about)...
>
> Or PF_IO_WORKER's, they too run only in kernel mode... But iirc they
> do call task_work_run().
At least I see a lot of task_work usage in io_uring, and there are some
explicit calls to task_work_run() there...
>
> > + local_irq_save(flags);
> > + if (task_work_queued(¤t->nohz_full_work)) {
> > + ret = 0;
> > + goto out;
> > + }
> > +
> > + ret = task_work_add(current, ¤t->nohz_full_work, TWA_RESUME);
> > +out:
> > + local_irq_restore(flags);
> > + return ret;
>
> Hmm, why not
>
> local_irq_save(flags);
> if (task_work_queued(...))
> ret = 0;
> else
> ret = task_work_add(...);
Hehe, yes indeed!
Thanks!
--
Frederic Weisbecker
SUSE Labs
Powered by blists - more mailing lists