Thread (2 messages) 2 messages, 2 authors, 2025-10-27

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

From: Thomas Gleixner <hidden>
Date: 2025-10-27 08:54:39
Also in: lkml

On Mon, Oct 27 2025 at 10:41, Shrikanth Hegde wrote:
On 10/22/25 6:25 PM, Thomas Gleixner wrote:
quoted
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.
quoted
+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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help