next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi

[Song Liu]

On Thu, Mar 7, 2024 at 11:02 AM Puranjay Mohan <puranjay12 at gmail.com> wrote:
>
> On Thu, Mar 7, 2024 at 7:34 PM Mark Brown <broonie at kernel.org> wrote:
> >
> > On Thu, Mar 07, 2024 at 10:16:21AM -0800, Song Liu wrote:
> > > On Thu, Mar 7, 2024 at 8:36 AM Mark Brown <broonie at kernel.org> wrote:
> >
> > > > The KernelCI bisection bot found a boot regression n today's -next on
> > > > qemu arm64 UEFI platforms with 64K pages which was bisected to commit
> > > > 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management").
> > > > We OOM quite early in boot:
> >
> > > IIUC, 64kB pages means 512MB PMD. I think that's indeed too big. We
> > > will need some logic to limit such cases.
>
> As far as I understand, we need the prog pack to be PMD sized so it is
> allocated as a huge page
> and if we limit this then vmalloc() will not allocate a huge page and
> the performance benefit will be lost.

bpf_prog_pack gives benefits without using PMD pages. For arm64
with 64kB page, even bpf_prog_pack of 64kB can fit multiple bpf
programs in it. OTOH, 512MB is really big.

How about we do something like the following?

Thanks,
Song

diff --git i/kernel/bpf/core.c w/kernel/bpf/core.c
index 9ee4536d0a09..1fe05c280e31 100644
--- i/kernel/bpf/core.c
+++ w/kernel/bpf/core.c
@@ -888,7 +888,15 @@ static LIST_HEAD(pack_list);
  * CONFIG_MMU=n. Use PAGE_SIZE in these cases.
  */
 #ifdef PMD_SIZE
-#define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes())
+  /* PMD_SIZE is really big for some archs. It doesn't make sense to
+   * reserve too much memory in one allocation. Cap BPF_PROG_PACK_SIZE to
+   * 2MiB * num_possible_nodes().
+   */
+  #if PMD_SIZE <= (1 << 21)
+    #define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes())
+  #else
+    #define BPF_PROG_PACK_SIZE ((1 << 21) * num_possible_nodes())
+  #endif
 #else
 #define BPF_PROG_PACK_SIZE PAGE_SIZE
 #endif