[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whadDF2MGN_THUo-n9S-m9isA-+vwhMeVvwGvmuZaYb6Q@mail.gmail.com>
Date: Sun, 24 Apr 2022 10:43:30 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Song Liu <songliubraving@...com>
Cc: Christoph Hellwig <hch@...radead.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
open list <linux-kernel@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Kernel Team <Kernel-team@...com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>
Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP
[ I see that you posted a new version of the series, but I wasn't cc'd
on that one, so I'm replying to the old thread instead ]
On Sat, Apr 16, 2022 at 12:55 PM Song Liu <songliubraving@...com> wrote:
>
> Patch 2/4 enables huge pages for large hash.
I decided that for 5.18, we want to at least fix the performance
regression on powerpc, so I've applied the 2/4 patch to enable huge
pages for the large hashes.
I also enabled them for kvmalloc(), since that seemed like the one
ObviouslySafe(tm) case of vmalloc use (famous last words, maybe I'll
be informed of somebody who still did odd protection games on the
result, but that really sounds invalid with the whole SLUB component).
I'm not touching the bpf parts. I think that's a 5.19 issue by now,
and since it's new, there's no equivalent performance regression
issue.
Linus
Powered by blists - more mailing lists