From: "Maurizio Lombardi" <mlombard@bsdbackstore.eu>
To: "Mikhail Gavrilov" <mikhail.v.gavrilov@gmail.com>,
"Keith Busch" <kbusch@kernel.org>
Cc: "Christoph Hellwig" <hch@lst.de>, <axboe@kernel.dk>,
<linux-nvme@lists.infradead.org>,
"Linux List Kernel Mailing" <linux-kernel@vger.kernel.org>,
"Linux regressions mailing list" <regressions@lists.linux.dev>
Subject: Re: 6.13/regression/bisected - new nvme timeout errors
Date: Mon, 24 Mar 2025 11:48:39 +0100 [thread overview]
Message-ID: <D8OFRDU1AVWC.1G6DIBZPLJ78@bsdbackstore.eu> (raw)
In-Reply-To: <CABXGCsMd_xv8jPDF_sFYhwd8GtANZ23nbaSJuCxQRO7cjPtgWg@mail.gmail.com>
On Sun Mar 23, 2025 at 10:49 AM CET, Mikhail Gavrilov wrote:
> On Thu, Mar 6, 2025 at 8:19 PM Keith Busch <kbusch@kernel.org> wrote:
>>
>> >
>> > nvme-pci: reverse request order in nvme_queue_rqs
>>
>> The patch here uses the order recieved to dispatch commands in
>> consequetive submission queue entries, which is supposed to be the
>> desired behavior for any device. I did some testing on mailine, and it
>> sure looks like the order the driver does this is optimal, so I'm not
>> sure what's going on with your observation.
>>
>> Do you have a scheduler enabled on your device?
>>
>> How are you generating IO? Is it a pattern I should be able to replicate
>> with 'fio'?
>
> Sorry for not answering for a long time, but all because I was testing
> the off-list patch that was sent to me by Maurizio Lombardi.
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 950289405ef2..990d9ef1eef9 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -989,6 +989,9 @@ static void nvme_submit_cmds(struct nvme_queue
> *nvmeq, struct rq_list *rqlist)
> {
> struct request *req;
>
> + if (rq_list_empty(rqlist))
> + return;
> +
> spin_lock(&nvmeq->sq_lock);
> while ((req = rq_list_pop(rqlist))) {
> struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
>
> And I want to say right away that this patch solved my problem. I
> double checked, and both times the system worked for 4 days without
> errors:
>
Glad to hear it worked!
Keith, I think the problem here is simply that nvme_write_sq_db() ends up
being called even when the rqlist is empty and this couldn't happen before
the changes introduced by commit "nvme-pci: reverse request order in
nvme_queue_rqs".
If you say that this change makes sense I can submit a formal patch.
Maurizio
prev parent reply other threads:[~2025-03-24 11:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 21:58 6.13/regression/bisected - new nvme timeout errors Mikhail Gavrilov
2025-02-10 8:47 ` Mikhail Gavrilov
2025-03-05 22:44 ` Mikhail Gavrilov
2025-03-06 15:19 ` Keith Busch
2025-03-23 9:49 ` Mikhail Gavrilov
2025-03-24 10:48 ` Maurizio Lombardi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D8OFRDU1AVWC.1G6DIBZPLJ78@bsdbackstore.eu \
--to=mlombard@bsdbackstore.eu \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox