From: Song Liu <song@kernel.org>
To: <linux-kernel@vger.kernel.org>, <bpf@vger.kernel.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 bpf-next 0/5] bpf_prog_pack followup
Date: Sun, 15 May 2022 22:40:46 -0700 [thread overview]
Message-ID: <20220516054051.114490-1-song@kernel.org> (raw)
Resending the set, as the original ones didn't make through the maillist.
As of 5.18-rc6, x86_64 uses bpf_prog_pack on 4kB pages. This set contains
two followups:
1/5 - 3/5 fills unused part of bpf_prog_pack with illegal instructions.
4/5 - 5/5 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 (5):
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
arch/x86/include/asm/text-patching.h | 1 +
arch/x86/kernel/alternative.c | 70 ++++++++++++++++++++++++----
arch/x86/kernel/module.c | 21 +++++++++
arch/x86/net/bpf_jit_comp.c | 5 ++
include/linux/bpf.h | 1 +
include/linux/moduleloader.h | 5 ++
kernel/bpf/core.c | 30 ++++++++----
kernel/module.c | 8 ++++
8 files changed, 122 insertions(+), 19 deletions(-)
--
2.30.2
next reply other threads:[~2022-05-16 5:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 5:40 Song Liu [this message]
2022-05-16 5:40 ` [PATCH bpf-next 1/5] bpf: fill new bpf_prog_pack with illegal instructions Song Liu
2022-05-16 5:40 ` [PATCH bpf-next 2/5] x86/alternative: introduce text_poke_set Song Liu
2022-05-17 19:16 ` Edgecombe, Rick P
2022-05-17 21:09 ` Song Liu
2022-05-18 6:58 ` Song Liu
2022-05-18 7:45 ` Peter Zijlstra
2022-05-18 15:32 ` Song Liu
2022-05-18 17:09 ` Peter Zijlstra
2022-05-18 18:34 ` Song Liu
2022-05-19 7:38 ` Peter Zijlstra
2022-05-16 5:40 ` [PATCH bpf-next 3/5] bpf: introduce bpf_arch_text_invalidate for bpf_prog_pack Song Liu
2022-05-16 5:40 ` [PATCH bpf-next 4/5] module: introduce module_alloc_huge Song Liu
2022-05-18 6:28 ` Song Liu
2022-05-16 5:40 ` [PATCH bpf-next 5/5] bpf: use module_alloc_huge for bpf_prog_pack Song Liu
2022-05-17 19:15 ` Edgecombe, Rick P
2022-05-17 21:08 ` Song Liu
2022-05-17 23:58 ` Edgecombe, Rick P
2022-05-18 6:25 ` Song Liu
2022-05-18 6:34 ` Song Liu
2022-05-18 16:49 ` Edgecombe, Rick P
2022-05-18 18:31 ` Song Liu
2022-05-19 6:42 ` Song Liu
2022-05-19 16:56 ` Edgecombe, Rick P
2022-05-19 18:25 ` Song Liu
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=20220516054051.114490-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=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.