Re: [PATCH 2/2] sched: Move task_mm_cid_work to RCU callback

[Joel Fernandes]

On Mon, Dec 2, 2024 at 9:34 AM Mathieu Desnoyers
<mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>
> += CC RCU maintainers, reviewers and list.
> += RSEQ maintainers.
>
> On 2024-12-02 09:07, Gabriele Monaco wrote:
> > Currently, the task_mm_cid_work function is called in a task work
> > triggered by a scheduler tick. This can delay the execution of the
> > task for the entire duration of the function.
> >
> > This patch runs the task_mm_cid_work in the RCU callback thread rather
> > than in the task context before returning to userspace.
> >
> > The main advantage of this change is that the function can be offloaded
> > to a different CPU and even preempted by RT tasks.
> >
> > On a busy system, this may mean the function gets called less often, but
> > the current behaviour already doesn't provide guarantees.
>
> I've used the same task work pattern as NUMA here. What makes it
> OK for NUMA and not for mm_cid ?
>
> I wonder why we'd want to piggy-back on call_rcu here when
> this has nothing to do with RCU. There is likely a characteristic
> of the call_rcu worker threads that we want to import into
> task_tick_mm_cid(), or change task_work.c to add a new flag
> that says the work can be dispatched to any CPU.

Also there is no guarantee that RCU callback will run within a thread
context (example, some configurations run it in softirq). Further,
call_rcu() usage as shown in this patch can also delay callback runs
by seconds (with RCU_LAZY enabled).

See also #5 in checklist: https://docs.kernel.org/RCU/checklist.html

thanks,

 - Joel