Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i06494636:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a
Mime-Version: 1.0
Message-Id: <e8317df3-7955-4109-981c-f85f0416ce0f@www.fastmail.com>
In-Reply-To: <2f252399-0e30-4465-8c02-3f42c145174a@www.fastmail.com>
References: <dcd8beea-d2d9-e692-6e5d-c96b2d29dfd1@suse.com>
 <2b8a38fa-f15f-45e8-8caa-61c5f8cd52de@www.fastmail.com>
 <7c830487-95a6-b008-920b-8bc4a318f10a@applied-asynchrony.com>
 <20220817114933.66c4g4xjsi4df2tg@quack3>
 <85a141ae-56a7-4dcd-b75a-04be4b276b3a@www.fastmail.com>
 <20220817163059.kigrvdfmxfswmhls@quack3>
 <f6f899a5-97e2-460f-ad73-73d4b5e38eb6@www.fastmail.com>
 <51cd43f9-ab6b-4dd6-814f-e0c1ace3143c@www.fastmail.com>
 <20220817181554.znqljc6mmci45ukd@quack3>
 <e4c260da-2df7-49a3-a8dc-1d3fc7ca12a0@www.fastmail.com>
 <20220817183335.47a4ao26wjopavo2@quack3>
 <2f252399-0e30-4465-8c02-3f42c145174a@www.fastmail.com>
Date:   Wed, 17 Aug 2022 15:23:43 -0400
From:   "Chris Murphy" <lists@colorremedies.com>
To:     "Jan Kara" <jack@suse.cz>
Cc:     =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= <holger@applied-asynchrony.com>,
        "Nikolay Borisov" <nborisov@suse.com>,
        "Jens Axboe" <axboe@kernel.dk>,
        "Paolo Valente" <paolo.valente@linaro.org>,
        Linux-RAID <linux-raid@vger.kernel.org>,
        linux-block <linux-block@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "Josef Bacik" <josef@toxicpanda.com>
Subject: Re: stalling IO regression since linux 5.12, through 5.18
Content-Type: text/plain
Precedence: bulk


On Wed, Aug 17, 2022, at 2:54 PM, Chris Murphy wrote:
> On Wed, Aug 17, 2022, at 2:33 PM, Jan Kara wrote:
>> On Wed 17-08-22 14:18:01, Chris Murphy wrote:
>>> 
>>> 
>>> On Wed, Aug 17, 2022, at 2:15 PM, Jan Kara wrote:
>>> 
>>> > OK, if this indeed passes then b6e68ee82585 ("blk-mq: Improve performance
>>> > of non-mq IO schedulers with multiple HW queues") might be what's causing
>>> > issues (although I don't know how yet...).
>>> 
>>> I can revert it from 5.12.0 and try. Let me know which next test is preferred :)
>>
>> Let's try to revert this first so that we have it narrowed down what
>> started causing the issues. 
>
> OK I've reverted b6e68ee82585, and removing 
> megaraid_sas.host_tagset_enable=0, and will restart the workload...
>
> Usually it's within 10 minutes but the newer the kernel it seems the 
> longer it takes, or the more things I have to throw at it. The problem 
> doesn't reproduce at all with 5.19 series unless I also run a separate 
> dnf install, and that only triggers maybe 1 in 3 times.

What I'm seeing is similar to 5.18 and occasionally 5.19...

top reports high %wa, above 30% sometimes above 60%, and increasing load (48 cpus so load 48 is OK, but this is triple digits which never happens on 5.11 series kernels).

IO pressure is 10x higher than with mq-deadline (or bfq on 5.11 series kernel) 40-50% right now

iotop usually craters to 0 by now, but it's near normal.

So I think b6e68ee82585 is s contributing factor. But isn't the only factor. I'm going to let this keep running and see if it matures into the more typical failure pattern.


-- 
Chris Murphy