/sys/devices/system/cpu/possible is immutable?

Junyeong Jeong esrse.jeong at gmail.com
Thu Mar 18 10:10:18 EDT 2021


Hello everyone :)

I hope that kernelnewbies mailing list is a suitable place for asking my
question.

I wonder that possible-CPU-mask(/sys/devices/system/cpu/possible) can be
changed after boot in some way or other. I read that it is fixed at boot
time (https://elixir.bootlin.com/linux/v5.8/source/include/linux/cpumask.h#L50).
But I am not convinced that it is really immutable even if some cgroup
or virtualization magic is used.

Let me account for why I am curious about it.
Nowadays I am developing BPF library written in rust language.
In order to call `bpf_lookup_elem()` to get values from
BPF_MAP_TYPE_PERCPU_ARRAY in userspace, we need to know the correct
number of per-cpu areas before calling it. Because an out-buffer for
multiple per-cpu values should be allocated and passed to the
`bpf_lookup_elem()`. But this process is strongly based on the
assumption that the number of per-cpu area is always immutable.

I am referring to /sys/devices/system/cpu/possible file to get to know
the number of per-cpu areas. I don't know the better way for figuring
out the number. What I am anxious about is that the number of per-cpu
areas varies from time to time under some circumstances with cgroup or
virtualization magic.

So I checked some cgroup and virtualization ordinary use-cases which did
not affect the possible-CPU-mask.

--
1.
$ docker run --cpuset-cpus=0-3 -it ubuntu:20.10 bash

This does not affect /sys/devices/system/cpu/possible at all. The value
it contains is the same with the value of the host machine.

2.
$ virsh setvcpus --current ubuntu20.10 5

Before starting guest OS, the number of maximum vCPU was set to 8 and
current vCPU was set to 4. While guest OS is running, I changed the
number of vCPU to 5. And _inside guest OS_, I enabled the new CPU by
setting /sys/devices/system/cpu/cpu4/online to 1. But
/sys/devices/system/cpu/possible of guest OS did not change as expected.
--

While I was conducting some tests, I realized that it's not possible to
prove the immutability of possible-CPU-mask using inductive
method. Because there must be some corner cases that I can never
imagine.


Can anyone explain that possible-CPU-mask and the number of per-cpu
areas never change after boot-time even by cgroup magic or some tricks
from outside of hypervisors?

Thanks,
    Junyeong



More information about the Kernelnewbies mailing list