All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junyeong Jeong <esrse.jeong@gmail.com>
To: kernel-janitors@vger.kernel.org
Subject: /sys/devices/system/cpu/possible can be changed during runtime?
Date: Mon, 15 Mar 2021 14:35:06 +0900	[thread overview]
Message-ID: <87o8fl0yf4.fsf@gmail.com> (raw)

Hello everyone :D

I wonder that possible-CPU-mask(/sys/devices/system/cpu/possible) can be
changed during runtime. I read that it is fixed at boot time, but I am
not sure that it is really immutable even if some cgroup or
virtualization magic is used.

I am referring to /sys/devices/system/cpu/possible file to get to know
the number of per-cpu areas. In userspace, I call `bpf_lookup_elem()` to
get values at index from BPF array map of which type is
BPF_MAP_TYPE_PERCPU_ARRAY.  And the length of the gained values is the
same with the number of per-cpu areas and in turn it is the same with
the number of possible CPUs.

I am anxious that this varies from time to time under some
circumstances. So I checked some cgroup and virtualization use-cases
which did not affect the possible-CPU-mask.

$ docker run --cpuset-cpus=0-3 -it ubuntu:20.10 bash  # cgroup cpuset
$ virsh setvcpus --current ubuntu20.10 5  # hotplug cpu while guest os is running..

But while conducting this I realized that it's not possible to prove the
immutability of possible-CPU-mask using inductive method.

Can anyone explain that it will not happen that possible-CPU-mask
changes after boot-time even with cgroup magic or some tricks from
outside of hypervisors?

Thanks,

             reply	other threads:[~2021-03-15  5:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15  5:35 Junyeong Jeong [this message]
2021-03-17  8:31 ` /sys/devices/system/cpu/possible can be changed during runtime? Dan Carpenter
2021-03-17 13:02   ` Junyeong Jeong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8fl0yf4.fsf@gmail.com \
    --to=esrse.jeong@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.