From: Claudio Imbrenda <firstname.lastname@example.org>
To: Song Liu <email@example.com>
Cc: Christoph Hellwig <firstname.lastname@example.org>,
Nicholas Piggin <email@example.com>,
Song Liu <firstname.lastname@example.org>,
Linux Memory Management List <email@example.com>,
bpf <firstname.lastname@example.org>, Networking <email@example.com>,
X86 ML <firstname.lastname@example.org>, Alexei Starovoitov <email@example.com>,
Daniel Borkmann <firstname.lastname@example.org>,
Kernel Team <Kernelemail@example.com>,
Subject: Re: [PATCH bpf 0/4] introduce HAVE_ARCH_HUGE_VMALLOC_FLAG for bpf_prog_pack
Date: Fri, 8 Apr 2022 12:08:31 +0200 [thread overview]
Message-ID: <20220408120831.69b80310@p-imbrenda> (raw)
On Thu, 7 Apr 2022 19:57:25 +0000
Song Liu <firstname.lastname@example.org> wrote:
> Hi Nicholas and Claudio,
> > On Apr 5, 2022, at 4:54 PM, Song Liu <email@example.com> wrote:
> >> On Apr 5, 2022, at 12:07 AM, Christoph Hellwig <firstname.lastname@example.org> wrote:
> >> On Fri, Apr 01, 2022 at 10:22:00PM +0000, Song Liu wrote:
> >>>>> Please fix the underlying issues instead of papering over them and
> >>>>> creating a huge maintainance burden for others.
> >>> After reading the code a little more, I wonder what would be best strategy.
> >>> IIUC, most of the kernel is not ready for huge page backed vmalloc memory.
> >>> For example, all the module_alloc cannot work with huge pages at the moment.
> >>> And the error Paul Menzel reported in drm_fb_helper.c will probably hit
> >>> powerpc with 5.17 kernel as-is? (trace attached below)
> >>> Right now, we have VM_NO_HUGE_VMAP to let a user to opt out of huge pages.
> >>> However, given there are so many users of vmalloc, vzalloc, etc., we
> >>> probably do need a flag for the user to opt-in?
> >>> Does this make sense? Any recommendations are really appreciated.
> >> I think there is multiple aspects here:
> >> - if we think that the kernel is not ready for hugepage backed vmalloc
> >> in general we need to disable it in powerpc for now.
> > Nicholas and Claudio,
> > What do you think about the status of hugepage backed vmalloc on powerpc?
> > I found module_alloc and kvm_s390_pv_alloc_vm() opt-out of huge pages.
> > But I am not aware of users that benefit from huge pages (except vfs hash,
> > which was mentioned in 8abddd968a30). Does an opt-in flag (instead of
> > current opt-out flag, VM_NO_HUGE_VMAP) make sense to you?
> Could you please share your comments on this? Specifically, does it make
> sense to replace VM_NO_HUGE_VMAP with an opt-in flag? If we think current
> opt-out flag is better approach, what would be the best practice to find
> all the cases to opt-out?
An opt in flag would surely make sense, and it would be more backwards
compatible with existing code. That way each user can decide whether to
fix the code to allow for hugepages, if possible at all. For example,
the case you mentioned for s390 (kvm_s390_pv_alloc_vm) would not be
fixable, because of a hardware limitation (the whole area _must_ be
mapped with 4k pages)
If the consensus were to keep the current opt-put, then I guess each
user would have to check each usage of vmalloc and similar, and see if
anything breaks. To be honest, I think an opt-out would only be
possible after having the opt-in for a (long) while, when most users
would have fixed their code.
In short, I fully support opt-in.
> > Thanks,
> > Song
> >> - if we think even in the longer run only some users can cope with
> >> hugepage backed vmalloc we need to turn it into an opt-in in
> >> general and not just for x86
> >> - there still to appear various unresolved underlying x86 specific
> >> issues that need to be fixed either way
next prev parent reply other threads:[~2022-04-08 10:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 22:56 [PATCH bpf 0/4] introduce HAVE_ARCH_HUGE_VMALLOC_FLAG for bpf_prog_pack Song Liu
2022-03-30 22:56 ` [PATCH bpf 1/4] x86: disable HAVE_ARCH_HUGE_VMALLOC Song Liu
2022-03-30 23:47 ` Thomas Gleixner
2022-03-30 22:56 ` [PATCH bpf 2/4] vmalloc: introduce HAVE_ARCH_HUGE_VMALLOC_FLAG Song Liu
2022-03-30 23:40 ` Edgecombe, Rick P
2022-03-31 0:26 ` Song Liu
2022-03-30 22:56 ` [PATCH bpf 3/4] x86: select HAVE_ARCH_HUGE_VMALLOC_FLAG for X86_64 Song Liu
2022-03-30 23:54 ` Thomas Gleixner
2022-03-31 0:30 ` Song Liu
2022-03-30 22:56 ` [PATCH bpf 4/4] bpf: use __vmalloc_node_range() with VM_TRY_HUGE_VMAP for bpf_prog_pack Song Liu
2022-03-31 0:00 ` Thomas Gleixner
2022-03-31 0:31 ` Song Liu
2022-03-31 0:04 ` [PATCH bpf 0/4] introduce HAVE_ARCH_HUGE_VMALLOC_FLAG " Edgecombe, Rick P
2022-03-31 0:46 ` Song Liu
2022-03-31 16:19 ` Edgecombe, Rick P
2022-03-31 5:37 ` Christoph Hellwig
2022-03-31 23:59 ` Song Liu
2022-04-01 22:22 ` Song Liu
2022-04-05 7:07 ` Christoph Hellwig
2022-04-05 23:54 ` Song Liu
2022-04-07 19:57 ` Song Liu
2022-04-08 10:08 ` Claudio Imbrenda [this message]
2022-04-08 21:22 ` Song Liu
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).