On 5/27/26 8:26 PM, Ilya Maximets wrote: > We should use the _SC_NPROCESSORS_CONF for the Linux case and > _SC_NPROCESSORS_ONLN for the non-Linux cases. I assume, that will > solve the problem, right?
Hi Ilya, Thanks for the review. I agree that using _SC_NPROCESSORS_CONF as the initial value for Linux is a better starting point. I tested the affected environment, and the EINVAL retry path from this patch is still needed there. The affected system is a QEMU/KVM VM configured for CPU hotplug, running Rocky Linux 9.7 with glibc 2.34: /sys/devices/system/cpu/possible: 0-159 /sys/devices/system/cpu/present: 0-19 /sys/devices/system/cpu/online: 0-19 But: getconf _NPROCESSORS_CONF: 20 getconf _NPROCESSORS_ONLN: 20 A small sched_getaffinity() test shows: CPU_ALLOC(20): sched_getaffinity() returns EINVAL CPU_ALLOC(64): sched_getaffinity() returns EINVAL CPU_ALLOC(128): sched_getaffinity() returns EINVAL CPU_ALLOC(160): sched_getaffinity() succeeds and returns 4 CPUs The tested process is limited to CPUs 6-9 on this system. So _SC_NPROCESSORS_CONF can still be smaller than the kernel affinity mask size on some systems. Would it make sense for v2 to use _SC_NPROCESSORS_CONF as the initial Linux value, but keep the EINVAL growth/retry path as a fallback? > Note: for the future, please, provide the sign-off tag in the following > format, if possible: > > Signed-off-by: Full Name <[email protected]> Thanks for the note. I will use this sign-off format in future patches: Signed-off-by: Wang Zhan <[email protected]> Thanks, Wang Zhan _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
