Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Wed, 13 Nov 2019 15:25:14 +0100
From:   Oleksandr Natalenko <oleksandr@natalenko.name>
To:     Paolo Valente <paolo.valente@linaro.org>
Cc:     Jens Axboe <axboe@kernel.dk>,
        linux-block <linux-block@vger.kernel.org>,
        linux-kernel@vger.kernel.org, ulf.hansson@linaro.org,
        linus.walleij@linaro.org, bfq-iosched@googlegroups.com,
        Chris Evich <cevich@redhat.com>,
        Patrick Dung <patdung100@gmail.com>,
        Thorsten Schubert <tschubert@bafh.org>
Subject: Re: [PATCH BUGFIX] block, bfq: deschedule empty bfq_queues not
 referred by any process
In-Reply-To: <2FB3736A-693E-44B9-9D1F-39AE0D016644@linaro.org>
References: <20191112074856.40433-1-paolo.valente@linaro.org>
 <bb393dcaa426786e0963cf0e70f0b062@natalenko.name>
 <2FB3736A-693E-44B9-9D1F-39AE0D016644@linaro.org>
User-Agent: Roundcube Webmail/1.4.0
Message-ID: <65fc0bffbcb2296d121b3d5a79108e76@natalenko.name>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 13.11.2019 14:52, Paolo Valente wrote:
>> I'm not sure if I see things right, but this commit along with v5.3.11 
>> kernel causes almost all boots to hang (for instance, on mounting the 
>> FS). Once the scheduler is changed to something else than BFQ (I set 
>> the I/O scheduler early via udev rule), multiple reboots go just fine.
>> 
> 
> If you switch back to bfq after the boot, can you still reproduce the 
> hang?

I didn't try to switch schedulers, but what I see now is once the system 
is able to boot with BFQ, the I/O can still hang on I/O burst (which for 
me happens to happen during VM reboot).

This may also not hang forever, but just slow down considerably. I've 
noticed this inside a KVM VM, not on a real HW.

>> Is this commit also applicable to 5.3 kernels?
> 
> It is.

OK, thanks for clarification.

-- 
   Oleksandr Natalenko (post-factum)