From: Song Liu <song@kernel.org>
To: <linux-kernel@vger.kernel.org>, <bpf@vger.kernel.org>,
<linux-mm@kvack.org>
Cc: <ast@kernel.org>, <daniel@iogearbox.net>, <peterz@infradead.org>,
<mcgrof@kernel.org>, <torvalds@linux-foundation.org>,
<rick.p.edgecombe@intel.com>, <kernel-team@fb.com>,
Song Liu <song@kernel.org>
Subject: [PATCH v4 bpf-next 0/8] bpf_prog_pack followup
Date: Fri, 20 May 2022 16:57:50 -0700 [thread overview]
Message-ID: <20220520235758.1858153-1-song@kernel.org> (raw)
Changes v3 => v4:
1. Shorten CC list on 4/8, so it is not dropped by the mail list.
Changes v2 => v3:
1. Fix issues reported by kernel test robot <lkp@intel.com>.
Changes v1 => v2:
1. Add WARN to set_vm_flush_reset_perms() on huge pages. (Rick Edgecombe)
2. Simplify select_bpf_prog_pack_size. (Rick Edgecombe)
As of 5.18-rc6, x86_64 uses bpf_prog_pack on 4kB pages. This set contains
a few followups:
1/8 - 3/8 fills unused part of bpf_prog_pack with illegal instructions.
4/8 - 5/8 enables bpf_prog_pack on 2MB pages.
The primary goal of bpf_prog_pack is to reduce iTLB miss rate and reduce
direct memory mapping fragmentation. This leads to non-trivial performance
improvements.
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.
bpf_prog_pack on 2MB pages may use slightly more memory for systems
without many BPF programs. However, such waste in memory (<2MB) is within
noisy for modern x86_64 systems.
Song Liu (8):
bpf: fill new bpf_prog_pack with illegal instructions
x86/alternative: introduce text_poke_set
bpf: introduce bpf_arch_text_invalidate for bpf_prog_pack
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/include/asm/text-patching.h | 1 +
arch/x86/kernel/alternative.c | 67 +++++++++++++++++++++++-----
arch/x86/kernel/module.c | 21 +++++++++
arch/x86/net/bpf_jit_comp.c | 5 +++
include/linux/bpf.h | 1 +
include/linux/moduleloader.h | 5 +++
include/linux/vmalloc.h | 7 +++
kernel/bpf/core.c | 43 ++++++++++--------
kernel/module.c | 8 ++++
mm/vmalloc.c | 5 +++
10 files changed, 134 insertions(+), 29 deletions(-)
--
2.30.2
next reply other threads:[~2022-05-21 0:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-20 23:57 Song Liu [this message]
2022-05-20 23:57 ` [PATCH v4 bpf-next 1/8] bpf: fill new bpf_prog_pack with illegal instructions Song Liu
2022-05-20 23:57 ` [PATCH v4 bpf-next 2/8] x86/alternative: introduce text_poke_set Song Liu
2022-05-20 23:57 ` [PATCH v4 bpf-next 3/8] bpf: introduce bpf_arch_text_invalidate for bpf_prog_pack Song Liu
2022-05-24 7:20 ` Mike Rapoport
2022-05-20 23:57 ` [PATCH v4 bpf-next 4/8] module: introduce module_alloc_huge Song Liu
2022-05-20 23:57 ` [PATCH v4 bpf-next 5/8] bpf: use module_alloc_huge for bpf_prog_pack Song Liu
2022-05-24 7:22 ` Mike Rapoport
2022-05-24 16:42 ` Edgecombe, Rick P
2022-06-17 23:05 ` Edgecombe, Rick P
2022-05-20 23:57 ` [PATCH v4 bpf-next 6/8] vmalloc: WARN for set_vm_flush_reset_perms() on huge pages Song Liu
2022-05-20 23:57 ` [PATCH v4 bpf-next 7/8] vmalloc: introduce huge_vmalloc_supported Song Liu
2022-05-20 23:57 ` [PATCH v4 bpf-next 8/8] bpf: simplify select_bpf_prog_pack_size Song Liu
2022-05-23 21:20 ` [PATCH v4 bpf-next 0/8] bpf_prog_pack followup patchwork-bot+netdevbpf
2022-06-20 11:11 ` Aaron Lu
2022-06-20 16:03 ` Song Liu
2022-06-21 1:31 ` Aaron Lu
2022-06-21 2:51 ` Song Liu
2022-06-21 3:25 ` Aaron Lu
2022-06-20 18:31 ` Luis Chamberlain
2022-06-21 1:45 ` Aaron Lu
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=20220520235758.1858153-1-song@kernel.org \
--to=song@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=torvalds@linux-foundation.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.