All of lore.kernel.org
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@fb.com>
To: Song Liu <song@kernel.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	Kernel Team <Kernel-team@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>, X86 ML <x86@kernel.org>
Subject: Re: [PATCH v5 bpf-next 0/5] bpf_prog_pack followup
Date: Fri, 24 Jun 2022 22:00:08 +0000	[thread overview]
Message-ID: <93DA8BBD-0599-4384-B73E-FAC1DC047D10@fb.com> (raw)
In-Reply-To: <20220624215712.3050672-1-song@kernel.org>

oops, wrong address for x86@. 

CC x86@kernel.org

> On Jun 24, 2022, at 2:57 PM, Song Liu <song@kernel.org> wrote:
> 
> This set is the second half of v4 [1].
> 
> Changes v4 => v5:
> 1. Rebase and resolve conflicts due to module.c split.
> 2. Update experiment results (below).
> 
> For our web service production benchmark, bpf_prog_pack on 4kB pages
> gives 0.5% to 0.7% more throughput than not using bpf_prog_pack.
> bpf_prog_pack on 2MB pages 0.6% to 0.9% more throughput than not using
> bpf_prog_pack. Note that 0.5% is a huge improvement for our fleet. I
> believe this is also significant for other companies with many thousand
> servers.
> 
> Update: Further experiments (suggested by Rick Edgecombe) showed that most
> of benefit on the web service benchmark came from less direct map
> fragmentation. The experiment is as follows:
> 
> Side A: 2MB bpf prog pack on a single 2MB page;
> Side B: 2MB bpf prog pack on 512x 4kB pages;
> 
> The system only uses about 200kB for BPF programs, but 2MB is allocated
> for bpf_prog_pack (for both A and B). Therefore, direct map fragmentation
> caused by BPF programs is elminated, and we are only measuring the
> performance difference of 1x 2MB page vs. ~50 4kB pages (we only use
> about 50 out of the 512 pages). For these two sides, the difference in
> system throughput is within the noise. I also measured iTLB-load-misses
> caused by bpf programs, which is ~300/s for case A, and ~1600/s for case B.
> The overall iTLB-load-misses is about 1.5M/s on these hosts. Therefore,
> we can clearly see 2MB page reduces iTLB misses, but the difference is not
> enough to have visible impact on system throughput.
> 
> Of course, the impact of iTLB miss will be more significant for systems
> with more BPF programs loaded.
> 
> [1] https://lore.kernel.org/bpf/20220520235758.1858153-1-song@kernel.org/
> 
> Song Liu (5):
>  module: introduce module_alloc_huge
>  bpf: use module_alloc_huge for bpf_prog_pack
>  vmalloc: WARN for set_vm_flush_reset_perms() on huge pages
>  vmalloc: introduce huge_vmalloc_supported
>  bpf: simplify select_bpf_prog_pack_size
> 
> arch/x86/kernel/module.c     | 21 +++++++++++++++++++++
> include/linux/moduleloader.h |  5 +++++
> include/linux/vmalloc.h      |  7 +++++++
> kernel/bpf/core.c            | 25 ++++++++++---------------
> kernel/module/main.c         |  8 ++++++++
> mm/vmalloc.c                 |  5 +++++
> 6 files changed, 56 insertions(+), 15 deletions(-)
> 
> --
> 2.30.2


      parent reply	other threads:[~2022-06-24 22:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24 21:57 [PATCH v5 bpf-next 0/5] bpf_prog_pack followup Song Liu
2022-06-24 21:57 ` [PATCH v5 bpf-next 1/5] module: introduce module_alloc_huge Song Liu
2022-07-01 23:20   ` Luis Chamberlain
2022-07-06  4:39     ` Song Liu
2022-07-07 20:11       ` Luis Chamberlain
2022-06-24 21:57 ` [PATCH v5 bpf-next 2/5] bpf: use module_alloc_huge for bpf_prog_pack Song Liu
2022-06-24 21:57 ` [PATCH v5 bpf-next 3/5] vmalloc: WARN for set_vm_flush_reset_perms() on huge pages Song Liu
2022-06-24 21:57 ` [PATCH v5 bpf-next 4/5] vmalloc: introduce huge_vmalloc_supported Song Liu
2022-06-24 21:57 ` [PATCH v5 bpf-next 5/5] bpf: simplify select_bpf_prog_pack_size Song Liu
2022-06-24 22:00 ` Song Liu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=93DA8BBD-0599-4384-B73E-FAC1DC047D10@fb.com \
    --to=songliubraving@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=song@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.