Bug 1212996

Summary: workload-libmicro-file mmap operations test declines >50% between 6.0 and 6.3
Product: [openSUSE] openSUSE Tumbleweed Reporter: Gabriel Krisman Bertazi <gabriel.bertazi>
Component: KernelAssignee: Gabriel Krisman Bertazi <gabriel.bertazi>
Status: CONFIRMED --- QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: gabriel.bertazi, jack, kernel-performance-bugs, mgorman
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Gabriel Krisman Bertazi 2023-07-04 18:23:14 UTC 
Dashboard:
  * http://perf-vm-lp.arch.suse.cz/marvin/dashboard-openSUSE-LEAP-15.4.html?filter=libmicro-file

Seems to affect all machines on the grid.  There is small variation on most file operations <10%, but mmap/munmap really stand out:

i.e. workload-libmicro-file-ext4/Parmesan:

                                    6.0               6.1         6.3
Time	mean95-mmap_rt128k   4.5700 ( 0.00%)  5.5975 (-22.48%) 6.4760(-41.71%)
Time	mean95-mmap_rt8k     1.5482 ( 0.00%)  2.3308 (-50.56%) 2.6692( -72.41%)
Time	mean95-mmap_t128k    0.9488 ( 0.00%)  1.6432 (-73.18%) 2.0493(-115.99%)
Time	mean95-mmap_t8k      0.9633 ( 0.00%)  1.6368 (-69.92%) 1.9668(-104.17%)
Time	mean95-mmap_wt128k  36.5464 ( 0.00%) 39.5990 ( -8.35%) 41.9538(-14.80%)
Time	mean95-mmap_wt8k    3.5521  ( 0.00%)  4.5164 ( -27.15%)	4.9287(-38.75%)

Seems like it first appeared on 6.1.  I'm investigating.
Comment 2 Jan Kara 2023-07-05 12:36:01 UTC 
Given this happens on many machines, I think it is a valid issue. If I should guess, I'd think this may be caused by commit d4af56c5c7c6 ("mm: start tracking VMAs with maple tree"). Mel was looking into various consequences this commit has AFAIR. It was definitely bisected down as a reason for gitsource benchmark regression as well.
Comment 3 Gabriel Krisman Bertazi 2023-07-13 19:33:12 UTC 
(In reply to Jan Kara from comment #2)
> Given this happens on many machines, I think it is a valid issue. If I
> should guess, I'd think this may be caused by commit d4af56c5c7c6 ("mm:
> start tracking VMAs with maple tree"). Mel was looking into various
> consequences this commit has AFAIR. It was definitely bisected down as a
> reason for gitsource benchmark regression as well.

you called it, Jan :).  I bisected it to:

commit d4af56c5c7c6781ca6ca8075e2cf5bc119ed33d1
Author: Liam R. Howlett <Liam.Howlett@Oracle.com>
Date:   Tue Sep 6 19:48:45 2022 +0000

    mm: start tracking VMAs with maple tree

CCing Mel.