All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Wang Jianchao <jianchao.wan9@gmail.com>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	Adam Manzanares <adam.manzanares@wdc.com>,
	Paolo Valente <paolo.valente@linaro.org>
Subject: Re: [PATCH 0/9] Improve I/O priority support
Date: Fri, 28 May 2021 09:28:43 -0700	[thread overview]
Message-ID: <feca5738-690c-3842-e5a8-998f0f5e3228@acm.org> (raw)
In-Reply-To: <b3878299-ae9b-d03a-eaa8-b1890afcbfe2@gmail.com>

On 5/27/21 7:05 PM, Wang Jianchao wrote:
> Does it really matter that issue IO request by the order of io priority ?
> 
> Given a device with a 32 depth queue and doesn't support io priority, even if
> we issue the request by the order of io priority, will the fw of device handle
> them by the same order ? Or in the other word, we always issue 32 io requests
> to device one time and then the fw of device decides how to handle them.
> The order of dispatching request from queue may only work when the device's
> queue is full and we have a deeper queue in io scheduler. And at this moment,
> maybe the user needs to check why their application saturates the block device.
> 
> As for the qos policy of io priority, it seems similar with wbt in which read,
> sync write and background write have different priority. Since we always want
> the io with higher priority to be served more by the device, adapting the depth
> of queue of different io priority may work ;)

Hi Jianchao,

Our conclusion from the extensive measurements we ran is that we cannot
reach our latency goals for high-priority I/O without I/O priority
support in the storage device. This is why we are working with device
vendors on implementing I/O priority support in the storage devices that
matter to us.

Thanks,

Bart.


  parent reply	other threads:[~2021-05-28 16:28 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27  1:01 [PATCH 0/9] Improve I/O priority support Bart Van Assche
2021-05-27  1:01 ` [PATCH 1/9] block/mq-deadline: Add several comments Bart Van Assche
2021-05-27  3:03   ` Damien Le Moal
2021-05-27  6:45   ` Hannes Reinecke
2021-05-27 19:30     ` Bart Van Assche
2021-05-27  8:43   ` Johannes Thumshirn
2021-05-27 15:13   ` Himanshu Madhani
2021-05-27  1:01 ` [PATCH 2/9] block/mq-deadline: Add two lockdep_assert_held() statements Bart Van Assche
2021-05-27  2:25   ` Chaitanya Kulkarni
2021-05-27  3:09   ` Damien Le Moal
2021-05-27  6:46   ` Hannes Reinecke
2021-05-27  8:44   ` Johannes Thumshirn
2021-05-27 15:14   ` Himanshu Madhani
2021-05-27  1:01 ` [PATCH 3/9] block/mq-deadline: Remove two local variables Bart Van Assche
2021-05-27  2:26   ` Chaitanya Kulkarni
2021-05-27  3:11   ` Damien Le Moal
2021-05-27  6:46   ` Hannes Reinecke
2021-05-27  8:44   ` Johannes Thumshirn
2021-05-27 15:15   ` Himanshu Madhani
2021-05-27  1:01 ` [PATCH 4/9] block/mq-deadline: Rename dd_init_queue() and dd_exit_queue() Bart Van Assche
2021-05-27  2:27   ` Chaitanya Kulkarni
2021-05-27  3:13   ` Damien Le Moal
2021-05-27 19:33     ` Bart Van Assche
2021-05-27  6:47   ` Hannes Reinecke
2021-05-27  8:44   ` Johannes Thumshirn
2021-05-27 15:16   ` Himanshu Madhani
2021-05-27  1:01 ` [PATCH 5/9] block/mq-deadline: Improve compile-time argument checking Bart Van Assche
2021-05-27  2:28   ` Chaitanya Kulkarni
2021-05-27  3:24   ` Damien Le Moal
2021-05-27 19:38     ` Bart Van Assche
2021-05-28  1:42       ` Damien Le Moal
2021-05-27  6:48   ` Hannes Reinecke
2021-05-27  8:49   ` Johannes Thumshirn
2021-05-27 15:19   ` Himanshu Madhani
2021-05-27  1:01 ` [PATCH 6/9] block/mq-deadline: Reduce the read expiry time for non-rotational media Bart Van Assche
2021-05-27  2:30   ` Chaitanya Kulkarni
2021-05-27  3:27   ` Damien Le Moal
2021-05-27 19:43     ` Bart Van Assche
2021-05-27  6:52   ` Hannes Reinecke
2021-05-27 15:20   ` Himanshu Madhani
2021-05-27  1:01 ` [PATCH 7/9] block/mq-deadline: Reserve 25% of tags for synchronous requests Bart Van Assche
2021-05-27  3:33   ` Damien Le Moal
2021-05-27 20:00     ` Bart Van Assche
2021-05-27  6:54   ` Hannes Reinecke
2021-05-27 19:55     ` Bart Van Assche
2021-05-27  1:01 ` [PATCH 8/9] block/mq-deadline: Add I/O priority support Bart Van Assche
2021-05-27  3:48   ` Damien Le Moal
2021-05-27 20:12     ` Bart Van Assche
2021-05-27  7:07   ` Hannes Reinecke
2021-05-27 20:23     ` Bart Van Assche
2021-05-28  1:40       ` Damien Le Moal
2021-05-27  1:01 ` [PATCH 9/9] block/mq-deadline: Add cgroup support Bart Van Assche
2021-05-27  7:09   ` Hannes Reinecke
2021-05-27  6:25 ` [PATCH 0/9] Improve I/O priority support Wang Jianchao
2021-05-27  8:05   ` Wang Jianchao
2021-05-27 18:40     ` Bart Van Assche
2021-05-28  2:05       ` Wang Jianchao
2021-05-28  8:43         ` Paolo Valente
2021-05-28 16:28         ` Bart Van Assche [this message]
2021-05-27  8:56 ` Johannes Thumshirn
2021-05-27 17:23   ` Chaitanya Kulkarni
2021-05-27 19:00     ` Bart Van Assche
2021-05-27 17:58 ` Adam Manzanares
2021-05-27 18:53   ` Bart Van Assche
2021-05-27 22:45     ` Adam Manzanares

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=feca5738-690c-3842-e5a8-998f0f5e3228@acm.org \
    --to=bvanassche@acm.org \
    --cc=adam.manzanares@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=jaegeuk@kernel.org \
    --cc=jianchao.wan9@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=paolo.valente@linaro.org \
    /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.