[patch V2 16/20] sched/mmcid: Provide new scheduler CID mechanism
Thomas Gleixner
tglx at linutronix.de
Mon Oct 27 19:54:36 AEDT 2025
On Mon, Oct 27 2025 at 10:41, Shrikanth Hegde wrote:
> On 10/22/25 6:25 PM, Thomas Gleixner wrote:
>> The MM CID management has two fundamental requirements:
>>
>> 1) It has to guarantee that at no given point in time the same CID is
>> used by concurrent tasks in userspace.
>>
>> 2) The CID space must not exceed the number of possible CPUs in a
>> system. While most allocators (glibc, tcmalloc, jemalloc) do not
>> care about that, there seems to be at least some LTTng library
>> depending on it.
>>
>> The CID space compaction itself is not a functional correctness
>> requirement, it is only a useful optimization mechanism to reduce the
>> memory foot print in unused user space pools.
>>
>
> Just wondering, if there is no user space request for CID, this whole mechanism
> should be under a static check to avoid any overhead?
The problem is that CID has been introduced unconditionally with RSEQ
and there is no mechanism to opt-in. So we could go and change the ABI,
but as you know that's generally frowned upon.
I thought about adding a static key, but that'd be systemwide and
would probably required to be opt-out for the same reason.
>> +static inline unsigned int mm_get_cid(struct mm_struct *mm)
>> +{
>> + unsigned int cid = __mm_get_cid(mm, READ_ONCE(mm->mm_cid.max_cids));
>> +
>> + for (; cid == MM_CID_UNSET; cpu_relax())
>
> This triggers an compile error on ppc64le.
>
> In file included from ./include/vdso/processor.h:10,
> from ./arch/powerpc/include/asm/processor.h:9,
> from ./include/linux/sched.h:13,
> from ./include/linux/sched/affinity.h:1,
> from kernel/sched/sched.h:8,
> from kernel/sched/rq-offsets.c:5:
> kernel/sched/sched.h: In function ‘mm_get_cid’:
> ./arch/powerpc/include/asm/vdso/processor.h:26:9: error: expected expression before ‘asm’
> 26 | asm volatile(ASM_FTR_IFCLR( \
> | ^~~
> kernel/sched/sched.h:3615:37: note: in expansion of macro ‘cpu_relax’
> 3615 | for (; cid == MM_CID_UNSET; cpu_relax())
>
Duh. Did not notice because x86 implements cpu_relax() as a static
inline while PPC has it as a plain macro define. Let me move it out of
the for() then.
Thanks,
tglx
More information about the Linuxppc-dev
mailing list