Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "song@kernel.org" <song@kernel.org>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"hch@lst.de" <hch@lst.de>, "x86@kernel.org" <x86@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Lu, Aaron" <aaron.lu@intel.com>
Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs
Date: Wed, 16 Nov 2022 22:47:04 +0000	[thread overview]
Message-ID: <cea2f9f81db0a5db9cdc1ed9089454ddbd28541b.camel@intel.com> (raw)
In-Reply-To: <Y3VlQcsiEi273S+n@bombadil.infradead.org>

On Wed, 2022-11-16 at 14:33 -0800, Luis Chamberlain wrote:
> More in lines with what I was hoping for. Can something just do
> the parallelization for you in one shot? Can bench alone do it for
> you?
> Is there no interest to have soemthing which generically showcases
> multithreading / hammering a system with tons of eBPF JITs? It may
> prove useful.
> 
> And also, it begs the question, what if you had another iTLB generic
> benchmark or genearl memory pressure workload running *as* you run
> the
> above? I as, as it was my understanding that one of the issues was
> the
> long term slowdown caused by the directmap fragmentation without
> bpf_prog_pack, and so such an application should crawl to its knees
> over time, and there should be numbers you could show to prove that
> too, before and after.

We did have some benchmarks that showed if your direct map was totally
fragmented (started from boot at 4k page size) what the regression was:

https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/