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

[Mathieu Desnoyers]

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.
https://www.efficios.com