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
