All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ziyang Zhang <ZiyangZhang@linux.alibaba.com>
To: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org,
	Andreas Hindborg <andreas.hindborg@wdc.com>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>
Subject: Re: [PATCH] ublk_drv: don't forward io commands in reserve order
Date: Tue, 22 Nov 2022 14:05:21 +0800	[thread overview]
Message-ID: <7744e3c1-65ae-7dec-1e50-5ccf6035ceeb@linux.alibaba.com> (raw)
In-Reply-To: <20221121155645.396272-1-ming.lei@redhat.com>

On 2022/11/21 23:56, Ming Lei wrote:
> Either ublk_can_use_task_work() is true or not, io commands are
> forwarded to ublk server in reverse order, since llist_add() is
> always to add one element to the head of the list.
> 
> Even though block layer doesn't guarantee request dispatch order,
> requests should be sent to hardware in the sequence order generated
> from io scheduler, which usually considers the request's LBA, and
> order is often important for HDD.
> 
> So forward io commands in the sequence made from io scheduler by
> aligning task work with current io_uring command's batch handling,
> and it has been observed that both can get similar performance data
> if IORING_SETUP_COOP_TASKRUN is set from ublk server.
> 
> Reported-by: Andreas Hindborg <andreas.hindborg@wdc.com>
> Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>

I have tested this with dd. Looks like we get the correct order:

ublk_queue_rq: qid 0 tag 2 sect 12288
__ublk_rq_task_work: complete: op 33, qid 0 tag 2 io_flags 1 addr 7ff16699e000 sect 12288
ublk_queue_rq: qid 0 tag 5 sect 13312
__ublk_rq_task_work: complete: op 33, qid 0 tag 5 io_flags 1 addr 7ff166818000 sect 13312
ublk_queue_rq: qid 0 tag 4 sect 14336
__ublk_rq_task_work: complete: op 33, qid 0 tag 4 io_flags 1 addr 7ff16689a000 sect 14336
ublk_queue_rq: qid 0 tag 6 sect 15360
__ublk_rq_task_work: complete: op 33, qid 0 tag 6 io_flags 1 addr 7ff166796000 sect 15360


Reviewed-by: ZiyangZhang <ZiyangZhang@linux.alibaba.com>

Regards,
Zhang

  reply	other threads:[~2022-11-22  6:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 15:56 [PATCH] ublk_drv: don't forward io commands in reserve order Ming Lei
2022-11-22  6:05 ` Ziyang Zhang [this message]
2022-11-22  8:00 ` Damien Le Moal
2022-11-24  2:00 ` Ming Lei
2022-11-24  3:37 ` Jens Axboe

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=7744e3c1-65ae-7dec-1e50-5ccf6035ceeb@linux.alibaba.com \
    --to=ziyangzhang@linux.alibaba.com \
    --cc=andreas.hindborg@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.