[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7a14d025ea4de25d4989777f651d51117fc0a47c.camel@intel.com>
Date: Wed, 13 Apr 2022 15:51:46 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "song@...nel.org" <song@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"hch@...radead.org" <hch@...radead.org>,
"ast@...nel.org" <ast@...nel.org>,
"rppt@...nel.org" <rppt@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"andrii@...nel.org" <andrii@...nel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mcgrof@...nel.org" <mcgrof@...nel.org>,
"imbrenda@...ux.ibm.com" <imbrenda@...ux.ibm.com>
Subject: Re: [PATCH v2 bpf 3/3] bpf: use vmalloc with VM_ALLOW_HUGE_VMAP for
bpf_prog_pack
CC Mike, who has been working on a direct map fragmentation solution.
[0]
On Tue, 2022-04-12 at 14:00 -0700, Song Liu wrote:
> Since I am still learning the vmalloc/module_alloc code, I think I am
> not really capable of commenting on the direction. From our use
> cases, we do see performance hit due to large number of BPF
> program fragmenting the page table. Kernel module, OTOH, is not
> too big an issue for us, as we usually build hot modules into the
> kernel. That being said, we are interested in making the huge page
> interface general for BPF program and kernel module. We can
> commit resources to this effort.
That sounds great. Please feel free to loop me in if you do.
[0]
https://lore.kernel.org/lkml/20220127085608.306306-1-rppt@kernel.org/
Powered by blists - more mailing lists