Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs

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

 



On Mon, Nov 14, 2022 at 12:45:16PM -0800, Song Liu wrote:
> On Sun, Nov 13, 2022 at 2:43 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> > >
> > > If RO data causes problems with direct map fragmentation, we can use
> > > similar logic. I think we will need another tree in vmalloc for this case.
> > > Since the logic will be mostly identical, I personally don't think adding
> > > another tree is a big overhead.
> >
> > Actually, it would be interesting to quantify memory savings/waste as the
> > result of using execmem_alloc()
> 
> From a random system in our fleet, execmem_alloc() saves:
> 
> 139 iTLB entries (1x 2MB entry vs, 140x 4kB entries), which is more than
> 100% of L1 iTLB and about 10% of L2 TLB.

Using 2M pages saves page table entries. They might be cached in iTLB and
might be not because on a loaded system large part of iTBL will cache
userspace mappings.
 
> It wastes 1.5MB memory, which is 0.0023% of system memory (64GB).
> 
> I believe this is clearly a good trade-off.

The actual trade-off would be for 1.5MB of memory for yet unknown, or at
least unpublished, performance improvement on a loaded system.
 
> Thanks,
> Song

-- 
Sincerely yours,
Mike.




[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