Re: [patch V3 20/20] sched/mmcid: Switch over to the new mechanism

[Mathieu Desnoyers]

On 2025-10-31 12:57, Thomas Gleixner wrote:
> On Thu, Oct 30 2025 at 12:07, Mathieu Desnoyers wrote:
> > On 2025-10-29 09:09, Thomas Gleixner wrote:
> >
> > > @@ -10702,10 +10758,43 @@ void sched_mm_cid_exit(struct task_struc
> > >    
> > >    	if (!mm || !t->mm_cid.active)
> > >    		return;
> > > +	/*
> > > +	 * Ensure that only one instance is doing MM CID operations within
> > > +	 * a MM. The common case is uncontended. The rare fixup case adds
> > > +	 * some overhead.
> > > +	 */
> > > +	scoped_guard(mutex, &mm->mm_cid.mutex) {
> >
> > When exiting from a mm where mm->mm_cid.users == 1 (read with
> > READ_ONCE()), can we do this without holding the mutex as an
> > optimization ?
>
> What's the optimization in that case? The mutex is uncontended and the
> extra instructions for taking and releasing it are so trivial that you
> can't measure it at all.

Fair enough.

> But aside of that this might race against a scheduled work which was
> initiated by mm_update_cpus_allowed(). So keeping it strictly serialized
> makes the code simple and race free :)

OK!

With the "eventally" -> "eventually" nit fixed:

Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>


--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com