Re: [patch V3 16/20] sched/mmcid: Provide new scheduler CID mechanism

Mathieu Desnoyers
2025-10-30T15:09:22Z

On 2025-10-29 09:09, Thomas Gleixner wrote:
> The MM CID management has two fundamental requirements:

This explanation is duplicated verbatim between the previous
infrastructure patch and this one. I recommend keeping only
one of the two copies and adding a cross-reference in case
people are looking for details.

> @@ -130,7 +132,10 @@ struct mm_cid_pcpu {
> * @mutex: Mutex to serialize forks and exits related to this mm
> */
> struct mm_mm_cid {
> + /* Hotpath read mostly members */
> struct mm_cid_pcpu __percpu *pcpu;
> + unsigned int percpu;
> + unsigned int transit;
> unsigned int max_cids;
> unsigned int nr_cpus_allowed;
> unsigned int users;

I'll repeat my concern about false-sharing between frequent "users"
updates and surrounding read-mostly fields.

> +
> +static __always_inline void mm_cid_schedout(struct task_struct *prev)
> +{
> + /* During mode transitions CIDs are temporary and need to be dropped */
> + if (likely(!cid_in_transit(prev->mm_cid.cid)))
> + return;
> +
> + mm_drop_cid(prev->mm, cid_from_transit_cid(prev->mm_cid.cid));
> + prev->mm_cid.cid = MM_CID_UNSET;

I wonder why the transition from per-task to per-cpu needs to drop the
per-task CIDs. Can't we just move them to the per-cpu CID tracker
instead ? This would save us a "thundering herd" effect on the
cid mask allocation when switching from per-task to per-cpu.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.