All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"song@kernel.org" <song@kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Cc: "daniel@iogearbox.net" <daniel@iogearbox.net>,
	"Torvalds, Linus" <torvalds@linux-foundation.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"kernel-team@fb.com" <kernel-team@fb.com>,
	"ast@kernel.org" <ast@kernel.org>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>
Subject: Re: [PATCH v4 bpf-next 5/8] bpf: use module_alloc_huge for bpf_prog_pack
Date: Fri, 17 Jun 2022 23:05:24 +0000	[thread overview]
Message-ID: <dd21cf251b519685e2d3b204b8c48746b93dc264.camel@intel.com> (raw)
In-Reply-To: <20220520235758.1858153-6-song@kernel.org>

On Fri, 2022-05-20 at 16:57 -0700, Song Liu wrote:
> Use module_alloc_huge for bpf_prog_pack so that BPF programs sit on
> PMD_SIZE pages. This benefits system performance by reducing iTLB
> miss
> rate. Benchmark of a real web service workload shows this change
> gives
> another ~0.2% performance boost on top of PAGE_SIZE bpf_prog_pack
> (which improve system throughput by ~0.5%).
> 
> Also, remove set_vm_flush_reset_perms() from alloc_new_pack() and use
> set_memory_[nx|rw] in bpf_prog_pack_free(). This is because
> VM_FLUSH_RESET_PERMS does not work with huge pages yet. [1]
> 
> [1] 
> https://lore.kernel.org/bpf/aeeeaf0b7ec63fdba55d4834d2f524d8bf05b71b.camel@intel.com/
> Suggested-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Song Liu <song@kernel.org>

Hi,

Per request, just wanted to make it clear I'm personally on board with
side-stepping VM_FLUSH_RESET_PERMS here because the way things are
headed it may change anyway, and this already does a better job at
minimizing eBPF JIT kernel shootdowns than VM_FLUSH_RESET_PERMS did
when it was introduced. The warning added in the other patch will
prevent accidents like the first version of the series. So that aspect
seems ok to me.

In general I think this series still needs more x86/mm scrutiny though.

Thanks,

Rick

  parent reply	other threads:[~2022-06-17 23:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 23:57 [PATCH v4 bpf-next 0/8] bpf_prog_pack followup Song Liu
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 [this message]
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=dd21cf251b519685e2d3b204b8c48746b93dc264.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --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=song@kernel.org \
    --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.