Messages in this thread | | | Date | Fri, 17 Jun 2022 15:55:35 +0800 | Subject | Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free | From | Rongwei Wang <> |
| |
On 6/13/22 9:50 PM, Christoph Lameter wrote: > On Sat, 11 Jun 2022, Rongwei Wang wrote: > >>> Ok so the idea is to take the lock only if kmem_cache_debug. That looks >>> ok. But it still adds a number of new branches etc to the free loop. >>> >>> Some performance tests would be useful. >> Hi Christoph >> >> Thanks for your time! >> Do you have some advice in benchmarks that need me to test? And I find that >> hackbench and lkp was used frequently in mm/slub.c commits[1,2]. But I have no >> idea how to use these two benchmarks test to cover the above changes. Can you >> give some examples? Thanks very much! > > > Hi Rongwei, > > Well run hackbench with an without the change. > > There are also synthetic benchmarks available at > https://gentwo.org/christoph/slub/tests/ Christoph, I refer [1] to test some data below. The slub_test case is same to your provided. And here you the result of its test (the baseline is the data of upstream kernel, and fix is results of patched kernel).
my test environment: arm64 vm (32 cores and 128G memory)
And I have removed 'slub_debug=UFPZ' in cmdline before testing the following two groups of data.
[1]https://lore.kernel.org/linux-mm/20200527103545.4348ac10@carbon/
Single thread testing
1. Kmalloc: Repeatedly allocate then free test
before (baseline) fix kmalloc kfree kmalloc kfree 10000 times 8 7 cycles 8 cycles 5 cycles 7 cycles 10000 times 16 4 cycles 8 cycles 3 cycles 6 cycles 10000 times 32 4 cycles 8 cycles 3 cycles 6 cycles 10000 times 64 3 cycles 8 cycles 3 cycles 6 cycles 10000 times 128 3 cycles 8 cycles 3 cycles 6 cycles 10000 times 256 12 cycles 8 cycles 11 cycles 7 cycles 10000 times 512 27 cycles 10 cycles 23 cycles 11 cycles 10000 times 1024 18 cycles 9 cycles 20 cycles 10 cycles 10000 times 2048 54 cycles 12 cycles 54 cycles 12 cycles 10000 times 4096 105 cycles 20 cycles 105 cycles 25 cycles 10000 times 8192 210 cycles 35 cycles 212 cycles 39 cycles 10000 times 16384 133 cycles 45 cycles 119 cycles 46 cycles
2. Kmalloc: alloc/free test
before (base) fix 10000 times kmalloc(8)/kfree 3 cycles 3 cycles 10000 times kmalloc(16)/kfree 3 cycles 3 cycles 10000 times kmalloc(32)/kfree 3 cycles 3 cycles 10000 times kmalloc(64)/kfree 3 cycles 3 cycles 10000 times kmalloc(128)/kfree 3 cycles 3 cycles 10000 times kmalloc(256)/kfree 3 cycles 3 cycles 10000 times kmalloc(512)/kfree 3 cycles 3 cycles 10000 times kmalloc(1024)/kfree 3 cycles 3 cycles 10000 times kmalloc(2048)/kfree 3 cycles 3 cycles 10000 times kmalloc(4096)/kfree 3 cycles 3 cycles 10000 times kmalloc(8192)/kfree 3 cycles 3 cycles 10000 times kmalloc(16384)/kfree 33 cycles 33 cycles
Concurrent allocs
before (baseline) fix Kmalloc N*alloc N*free(8) Average=17/18 Average=11/11 Kmalloc N*alloc N*free(16) Average=15/49 Average=9/11 Kmalloc N*alloc N*free(32) Average=15/40 Average=9/11 Kmalloc N*alloc N*free(64) Average=15/44 Average=9/10 Kmalloc N*alloc N*free(128) Average=15/42 Average=10/10 Kmalloc N*alloc N*free(256) Average=128/28 Average=71/22 Kmalloc N*alloc N*free(512) Average=206/34 Average=178/26 Kmalloc N*alloc N*free(1024) Average=762/37 Average=369/27 Kmalloc N*alloc N*free(2048) Average=327/58 Average=339/33 Kmalloc N*alloc N*free(4096) Average=2255/128 Average=1813/64
before (baseline) fix Kmalloc N*(alloc free)(8) Average=3 Average=3 Kmalloc N*(alloc free)(16) Average=3 Average=3 Kmalloc N*(alloc free)(32) Average=3 Average=3 Kmalloc N*(alloc free)(64) Average=3 Average=3 Kmalloc N*(alloc free)(128) Average=3 Average=3 Kmalloc N*(alloc free)(256) Average=3 Average=3 Kmalloc N*(alloc free)(512) Average=3 Average=3 Kmalloc N*(alloc free)(1024) Average=3 Average=3 Kmalloc N*(alloc free)(2048) Average=3 Average=3 Kmalloc N*(alloc free)(4096) Average=3 Average=3
According to the above data, It seems that no significant performance degradation in patched kernel. Plus, in concurrent allocs test, likes Kmalloc N*alloc N*free(1024), the data of 'fix' column is better than baseline (it looks less is better, if I am wrong, please let me know). And if you have other suggestions, I can try to test more data.
Thanks for your time! -wrw > > These measure the cycles that slab operations take. However, they are a > bit old and I think Pekka may have a newer version of these > patches. > > Greetings, > Christoph
| |