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.
--
Chris Murphy
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
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...
I ran this for 7 hours and the problem didn't happen.
--
Chris Murphy