On Thu, Mar 7, 2024 at 11:02 AM Puranjay Mohan <puranjay12@xxxxxxxxx> wrote:
>
> On Thu, Mar 7, 2024 at 7:34 PM Mark Brown <broonie@xxxxxxxxxx> 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@xxxxxxxxxx> 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
