On Jul 23, 2019, at 10:01 PM, Sultan Alsawaf <sultan@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