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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux