On 5/28/26 5:57 AM, Wang Zhan wrote: > 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 >
Hmm. OK. We need the loop for the hotplug case indeed. > 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? OK. Sounds good to me. I'll send some comments for the loop code in a separate reply. > >> 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! Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
