On 06/12/2022 17.08, Matthew Wilcox wrote:
On Tue, Dec 06, 2022 at 10:43:05AM +0100, Jesper Dangaard Brouer wrote:
On 05/12/2022 17.31, Matthew Wilcox wrote:
On Mon, Dec 05, 2022 at 04:34:10PM +0100, Jesper Dangaard Brouer wrote:
I have a micro-benchmark [1][2], that I want to run on this patchset.
Reducing the asm code 'text' size is less likely to improve a
microbenchmark. The 100Gbit mlx5 driver uses page_pool, so perhaps I can
run a packet benchmark that can show the (expected) performance improvement.
[1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/bench_page_pool_simple.c
[2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/bench_page_pool_cross_cpu.c
Appreciate it! I'm not expecting any performance change outside noise,
but things do surprise me. I'd appreciate it if you'd test with a
"distro" config, ie enabling CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP so
we show the most expensive case.
I've tested with [1] and [2] and the performance numbers are the same.
Microbench [1] is easiest to compare, and numbers below were basically
same for both with+without patchset.
Type:tasklet_page_pool01_fast_path Per elem: 16 cycles(tsc) 4.484 ns
Type:tasklet_page_pool02_ptr_ring Per elem: 47 cycles(tsc) 13.147 ns
Type:tasklet_page_pool03_slow Per elem: 173 cycles(tsc) 48.278 ns
The last line (with 173 cycles) is then pages are not recycled, but
instead returned back into systems page allocator. To related this to
something, allocating order-0 pages via normal page allocator API costs
approx 282 cycles(tsc) 78.385 ns on this system (with .config). I
believe page_pool is faster, because we leverage the bulk page allocator.
--Jesper
