From: Heiko Carstens <hca@linux.ibm.com>
To: Hou Tao <houtao@huaweicloud.com>
Cc: Yonghong Song <yonghong.song@linux.dev>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
kernel-team@fb.com, Martin KaFai Lau <martin.lau@kernel.org>,
Marc Hartmayer <mhartmay@linux.ibm.com>,
Mikhail Zaslonko <zaslonko@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 01/13] bpf: Add support for non-fix-size percpu mem allocation
Date: Thu, 16 Nov 2023 14:54:21 +0100 [thread overview]
Message-ID: <20231116135421.22287-A-hca@linux.ibm.com> (raw)
In-Reply-To: <379ff74e-cad2-919c-4130-adbe80d50a26@huaweicloud.com>
On Thu, Nov 16, 2023 at 09:15:26AM +0800, Hou Tao wrote:
> > If we have a machine with 8GB, 6 present CPUs and 512 possible CPUs (yes,
> > this is a realistic scenario) the memory consumption directly after boot
> > is:
> >
> > $ cat /sys/devices/system/cpu/present
> > 0-5
> > $ cat /sys/devices/system/cpu/possible
> > 0-511
>
> Will the present CPUs be hot-added dynamically and eventually increase
> to 512 CPUs ? Or will the present CPUs rarely be hot-added ? After all
> possible CPUs are online, will these CPUs be hot-plugged dynamically ?
> Because I am considering add CPU hotplug support for bpf mem allocator,
> so we can allocate memory according to the present CPUs instead of
> possible CPUs. But if the present CPUs will be increased to all possible
> CPUs quickly, there will be not too much benefit to support hotplug in
> bpf mem allocator.
You can assume that the present CPUs would change only very rarely. Even
though we are only talking about virtual CPUs in this case systems are
usually setup in a way that they have enough CPUs for their workload. Only
if that is not the case additional CPUs may be added (and brought online) -
which is usually much later than boot time.
Obviously the above is even more true for systems where you have to add new
CPUs in a physical way in order to change present CPUs.
So I guess it is fair to assume that if there is such a large difference
between present and possible CPUs, that this will also stay that way while
the system is running in most cases.
Or in other words: it sounds like it is worth to add CPU hotplug support
for the the bpf mem allocator (without that I would know what that would
really mean for the bpf code).
Note for the above numbers: I hacked the number of possible CPUs manually
in the kernel code just to illustrate the high memory consumption for the
report. On a real system you would see "0-399" CPUs instead.
But that's just a minor detail.
prev parent reply other threads:[~2023-11-16 13:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230827152729.1995219-1-yonghong.song@linux.dev>
[not found] ` <20230827152734.1995725-1-yonghong.song@linux.dev>
2023-11-15 15:31 ` [PATCH bpf-next v3 01/13] bpf: Add support for non-fix-size percpu mem allocation Heiko Carstens
2023-11-15 15:54 ` Alexei Starovoitov
2023-11-16 1:15 ` Hou Tao
2023-11-16 5:52 ` Yonghong Song
2023-11-16 13:54 ` Heiko Carstens [this message]
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=20231116135421.22287-A-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=houtao@huaweicloud.com \
--cc=kernel-team@fb.com \
--cc=linux-s390@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=mhartmay@linux.ibm.com \
--cc=yonghong.song@linux.dev \
--cc=zaslonko@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox