All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.