[libvirt] PATCH 0/2]: Fix CPU affinity management for NR_CPUS > 1024

Daniel P. Berrange berrange at redhat.com
Mon Nov 16 16:49:28 UTC 2009

The RHEL-6 Alpha kernels have defined NR_CPUS=4096

The glibc static cpu_set_t data type used with  sched_[gs]etaffinity() 
has been sized with

  # define __CPU_SETSIZE  1024

So any attempt to use sched_[gs]etaffinity() with a static cpu_set_t 
on a RHEL-6 kernel ends up with -EINVAL, even if the machine does not
physically have > 1024 CPUs. The syscall mandates that the cpu set
arg is large enough to hold entire of NR_CPUS.

Fairly recent gLibc's now provide an alternative dynamically allocated
cpu_set_t data type, where the app tells glibc how many CPUs it has to
be able to hold. Great, except, the kernel does not tell userspace what
NR_CPUS it has been compiled with. So apps have to a pick a starting
size, try the sched_[gs]etaffinity() call, catch EINVAL, enlarge the
cpuset, repeat, repeat, repeat until it works. 

This was going to be horrible to put into the qemu driver code, so
I've introduced a new  util/processinfo.[h,c] file providing APis for
getting/setting CPU affinity that use the dynamically allocate mask
libvirt defines in its public API.


More information about the libvir-list mailing list