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

Thomas Gleixner
2025-10-31T16:57:06Z

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.

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 :)

Thanks,

tglx