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.
>
> These qemu instances are only configured with 1G of RAM so that's rather
> large indeed.
I was able to reproduce this without UEFI as well, I used 600MB in
place of 1G. Prog pack tries to
allocate 512 MB and this causes the OOM panic.
Can we implement this in a way where if the memory can't be allocated
then we fallback to allocating less
memory rather than panicking. I don't know enough memory management to
know how it would be done.
Thanks,
Puranjay
