Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: "Josef Bacik" <josef@toxicpanda.com>,
	"René Rebe" <rene@exactcode.de>,
	linux-btrfs@vger.kernel.org
Subject: Re: [BUG] 500-2000% performance regression w/ 5.10
Date: Sat, 26 Dec 2020 14:23:59 +0200	[thread overview]
Message-ID: <79455913-ce1e-23d4-326c-9f229e1df8b7@suse.com> (raw)
In-Reply-To: <6df7ff08-b9bf-a06e-13a9-bf1c431920e4@toxicpanda.com>



On 24.12.20 г. 20:09 ч., Josef Bacik wrote:
> On 12/21/20 2:45 PM, René Rebe wrote:
>> Hey there,
>>
>> as a long time btrfs user I noticed some some things became very slow
>> w/ Linux kernel 5.10. I found a very simple test case, namely extracting
>> a huge tarball like:
>>
>>    tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst
>>
>> Why my external, USB3 road-warrior SSD on a Ryzen 5950x this
>> went from ~15 seconds w/ 5.9 to nearly 5 minutes in 5.10, or 2000%
>>
>> To rule out USB, I also tested a brand new PCIe 4.0 SSD, with
>> a similar, albeit not as shocking regression from 5.2 seconds
>> to ~34 seconds or∫~650%.
>>
>> Somehow testing that in a VM did over virtio did not produce
>> as different results, although it was already 35 seconds slow
>> with 5.9.
>>
>> # first bad commit: [38d715f494f2f1dddbf3d0c6e50aefff49519232]
>>    btrfs: use btrfs_start_delalloc_roots in shrink_delalloc
>>
>> Now just this single commit does obviously not revert cleanly,
>> and I did not have the time today to look into the rather more
>> complex code today.
>>
>> I hope this helps improve this for the next release, maybe you
>> want to test on bare metal, too.
>>
> 
> Alright to close the loop with this, this slipped through the cracks
> because I was doing a lot of performance related work, and specifically
> had been testing with these patches on top of everything
> 
> https://lore.kernel.org/linux-btrfs/cover.1602249928.git.josef@toxicpanda.com/
> 
> 
> These patches bring the performance up to around 40% higher than
> baseline.  In the meantime we'll probably push this partial revert into
> 5.10 stable so performance isn't sucking in the meantime.  Thanks,

For the sake of clarity it's important to note that baseline in this
case is kernel 4.19 (since the original regressions was spotted in 5.0).
There has already been a couple of open interpretations of what this
means e.g 40% better than 5.10, suggesting performance is worse.

> 
> Josef
> 

  parent reply	other threads:[~2020-12-26 12:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-21 19:45 [BUG] 500-2000% performance regression w/ 5.10 René Rebe
2020-12-22  8:28 ` Qu Wenruo
2020-12-22  9:12   ` Rene Rebe
2020-12-23  3:14 ` Josef Bacik
2020-12-23 19:41 ` Josef Bacik
2020-12-23 20:31   ` Holger Hoffstätte
2020-12-23 20:34     ` Josef Bacik
2020-12-24 18:09 ` Josef Bacik
2020-12-24 21:11   ` René Rebe
2020-12-26 12:24     ` Nikolay Borisov
2020-12-26 15:30       ` Rene Rebe
2020-12-26 12:23   ` Nikolay Borisov [this message]
2021-01-04  1:15   ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=79455913-ce1e-23d4-326c-9f229e1df8b7@suse.com \
    --to=nborisov@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rene@exactcode.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox