Re: [6.2 regression][bisected]discard storm on idle since v6.1-rc8-59-g63a7cb130718 discard=async - Linux regression tracking (Thorsten Leemhuis)

From: "Linux regression tracking (Thorsten Leemhuis)" <regressions@leemhuis.info>
To: Boris Burkov <boris@bur.io>, David Sterba <dsterba@suse.cz>
Cc: Chris Mason <clm@meta.com>, Christoph Hellwig <hch@infradead.org>,
	Linux regressions mailing list <regressions@lists.linux.dev>,
	Sergei Trofimovich <slyich@gmail.com>,
	Josef Bacik <josef@toxicpanda.com>,
	Christopher Price <pricechrispy@gmail.com>,
	anand.jain@oracle.com, clm@fb.com, dsterba@suse.com,
	linux-btrfs@vger.kernel.org
Subject: Re: [6.2 regression][bisected]discard storm on idle since v6.1-rc8-59-g63a7cb130718 discard=async
Date: Wed, 5 Apr 2023 10:17:01 +0200	[thread overview]
Message-ID: <fb5c2b8c-f1da-22e8-7e81-b1f79b2152ec@leemhuis.info> (raw)
In-Reply-To: <20230404193909.GC344341@zen>

On 04.04.23 21:39, Boris Burkov wrote:
> On Tue, Apr 04, 2023 at 09:22:05PM +0200, David Sterba wrote:
>> On Tue, Apr 04, 2023 at 11:51:51AM -0700, Boris Burkov wrote:
>>> Our reasonable options, as I see them:
>>> - back to nodiscard, rely on periodic trims from the OS.
>>
>> We had that before and it's a fallback in case we can't fix it but still
>> the problem would persist for anyone enabling async discard so it's only
>> limiting the impact.
>>
>>> - leave low iops_limit, drives stay busy unexpectedly long, conclude that
>>>   that's OK, and communicate the tuning/measurement options better.
>>
>> This does not sound user friendly, tuning should be possible but not
>> required by default. We already have enough other things that users need
>> to decide and in this case I don't know if there's enough information to
>> even make a good decision upfront.
>>
>>> - set a high iops_limit (e.g. 1000) drives will get back to idle faster.
>>> - change an unset iops_limit to mean truly unlimited async discard, set
>>>   that as the default, and anyone who cares to meter it can set an
>>>   iops_limit.
>>>
>>> The regression here is in drive idle time due to modest discard getting
>>> metered out over minutes rather than dealt with relatively quickly. So
>>> I would favor the unlimited async discard mode and will send a patch to
>>> that effect which we can discuss.
>>
>> Can we do options 3 and 4, i.e. set a high iops so that the batch gets
>> processed faster and (4) that there's the manual override to drop the
>> limit completely?
> 
> Yup, I'm on it.
> [...]

Thx everyone for looking into this and the fruitful discussion
yesterday, much appreciated.

/me will now get back to watching this only from afar and leave things
to the experts

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.