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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Subject: Re: [PATCH BUGFIX V2] block, bfq: fix operator in BFQQ_TOTALLY_SEEKY
From:   Paolo Valente <paolo.valente@linaro.org>
In-Reply-To: <aec3e7b1-c235-ddb1-62b2-4ad7a7246a35@kernel.dk>
Date:   Mon, 24 Jun 2019 21:18:17 +0200
Cc:     linux-block <linux-block@vger.kernel.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        Ulf Hansson <ulf.hansson@linaro.org>, linus.walleij@linaro.org,
        bfq-iosched@googlegroups.com, oleksandr@natalenko.name
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9A203CB-DDA2-4C67-A20C-A3CA7354E3FB@linaro.org>
References: <20190622204416.33871-1-paolo.valente@linaro.org>
 <aec3e7b1-c235-ddb1-62b2-4ad7a7246a35@kernel.dk>
To:     Jens Axboe <axboe@kernel.dk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> Il giorno 24 giu 2019, alle ore 18:12, Jens Axboe <axboe@kernel.dk> ha =
scritto:
>=20
> On 6/22/19 2:44 PM, Paolo Valente wrote:
>> By mistake, there is a '&' instead of a '=3D=3D' in the definition of =
the
>> macro BFQQ_TOTALLY_SEEKY. This commit replaces the wrong operator =
with
>> the correct one.
>=20
> A bit worrying that this wasn't caught in testing, as it would have
> resulted in _any_ queue being positive for totally seeky?
>=20

Fortunately there's a somewhat reassuring explanation.  The commit
introducing this macro prevented seeky queues from being considered
soft real-time.  And, to be more selective, it actually filtered out
only totally seeky queues, i.e., queues whose last I/O requests are
*all* random.  With this error, any seeky queue was considered totally
seeky.  This the broke (only) selectivity.

> Anyway, applied.
>=20

Thanks,
Paolo

> --=20
> Jens Axboe
>=20