linux-kernel - Re: [REGRESSION] 5-10% increase in IO latencies with nohz balance patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 Jan 2022 11:16:01 -0500
From:   Josef Bacik <josef@...icpanda.com>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     Thorsten Leemhuis <regressions@...mhuis.info>,
        peterz@...radead.org, vincent.guittot@...aro.org,
        torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-btrfs@...r.kernel.org, guro@...com, clm@...com
Subject: Re: [REGRESSION] 5-10% increase in IO latencies with nohz balance
 patch

On Wed, Dec 22, 2021 at 04:07:35PM +0000, Valentin Schneider wrote:
> 
> Hi,
> 
> On 22/12/21 13:42, Thorsten Leemhuis wrote:
> > What's the status here? Just wondering, because there hasn't been any
> > activity in this thread since 11 days and the festive season is upon us.
> >
> > Was the discussion moved elsewhere? Or is this still a mystery? And if
> > it is: how bad is it, does it need to be fixed before Linus releases 5.16?
> >
> 
> I got to the end of bisect #3 yesterday, the incriminated commit doesn't
> seem to make much sense but I've just re-tested it and there is a clear
> regression between that commit and its parent (unlike bisect #1 and #2):
> 
> 2127d22509aec3a83dffb2a3c736df7ba747a7ce mm, slub: fix two bugs in slab_debug_trace_open()
> write_clat_ns_p99     195395.92     199638.20      4797.01    2.17%
> write_iops             17305.79      17188.24       250.66   -0.68%
> 
> write_clat_ns_p99     195543.84     199996.70      5122.88    2.28%
> write_iops             17300.61      17241.86       251.56   -0.34%
> 
> write_clat_ns_p99     195543.84     200724.48      5122.88    2.65%
> write_iops             17300.61      17246.63       251.56   -0.31%
> 
> write_clat_ns_p99     195543.84     200445.41      5122.88    2.51%
> write_iops             17300.61      17215.47       251.56   -0.49%
> 
> 6d2aec9e123bb9c49cb5c7fc654f25f81e688e8c mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() 
> write_clat_ns_p99     195395.92     197942.30      4797.01    1.30%
> write_iops             17305.79      17246.56       250.66   -0.34%
> 
> write_clat_ns_p99     195543.84     196183.92      5122.88    0.33%
> write_iops             17300.61      17310.33       251.56    0.06%
> 
> write_clat_ns_p99     195543.84     196990.71      5122.88    0.74%
> write_iops             17300.61      17346.32       251.56    0.26%
> 
> write_clat_ns_p99     195543.84     196362.24      5122.88    0.42%
> write_iops             17300.61      17315.71       251.56    0.09%
> 
> It's pure debug stuff and AFAICT is a correct fix...
> @Josef, could you test that on your side?

Sorry, holidays and all that.  I see 0 difference between the two commits, and
no regression from baseline.  It'll take me a few days to recover from the
holidays, but I'll put some more effort into actively debugging wtf is going on
here on my side since we're all having trouble pinning down what's going on.
Thanks,

Josef