On Jul 23, 2019, at 10:01 PM, Sultan Alsawaf <sul...@kerneltoast.com> wrote: > > On Tue, Jul 23, 2019 at 10:56:05AM -0600, Andreas Dilger wrote: >> Do you have any kind of performance metrics that show this is an actual >> improvement in performance? This would be either macro-level benchmarks >> (e.g. fio, but this seems unlikely to show any benefit), or micro-level >> measurements (e.g. flame graph) that show a net reduction in CPU cycles, >> lock contention, etc. in this part of the code. > > Hi Andreas, > > Here are some basic micro-benchmark results: > > Before: > [ 3.162896] mb_cache_entry_create: AVG cycles: 75 > [ 3.054701] mb_cache_entry_create: AVG cycles: 78 > [ 3.152321] mb_cache_entry_create: AVG cycles: 77 > > After: > [ 3.043380] mb_cache_entry_create: AVG cycles: 68 > [ 3.194321] mb_cache_entry_create: AVG cycles: 71 > [ 3.038100] mb_cache_entry_create: AVG cycles: 69
This information should be included in the patch description, since that allows making a decision on whether the patch is worthwhile to land or not. > The performance difference is probably more drastic when free memory is low, > since an unnecessary call to kmem_cache_alloc() can result in a long wait for > pages to be freed. Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP
