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

Mathieu Desnoyers
2025-10-31T19:17:26Z

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@efficios.com>

--
Mathieu Desnoyers
EfficiOS Inc.