From: Damien Le Moal <dlemoal@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH 3/3] block/mq-deadline: Disable I/O prioritization in certain cases
Date: Wed, 13 Dec 2023 08:52:49 +0900 [thread overview]
Message-ID: <95ecba8c-9a1a-49c9-92c8-f45580bc9f95@kernel.org> (raw)
In-Reply-To: <8998e3cd-6bf1-4199-9e21-60fdfba37571@acm.org>
On 12/13/23 07:44, Bart Van Assche wrote:
> On 12/10/23 23:40, Damien Le Moal wrote:
>> On 12/9/23 03:40, Bart Van Assche wrote:
>>> My understanding is that blkcg_set_ioprio() is called from inside submit_bio()
>>> and hence that the reported issue cannot be solved by modifying F2FS. How about
>>> modifying the blk-ioprio policy such that it ignores zoned writes?
>>
>> I do not see a better solution than that at the moment. So yes, let's do that.
>> But please add a big comment in the code explaining why we ignore zoned writes.
>
> Hi Damien,
>
> We tested a patch for the blk-ioprio cgroup policy that makes it skip zoned writes.
> We noticed that such a patch is not sufficient to prevent unaligned write errors
> because some tasks have been assigned an I/O priority via the ionice command
> (ioprio_set() system call). I think it would be wrong to skip the assignment of an
> I/O priority for zoned writes in all code that can set an I/O priority. Since the
> root cause of this issue is the inability of the mq-deadline I/O scheduler to
> preserve the order for zoned writes with different I/O priorities, I think this
> issue should be fixed in the mq-deadline I/O scheduler.
Not necessarily. When the priority for an IO is set when a BIO is prepared, we
know where that priority come from:
1) The user kiocb through aio_reqprio
2) The process ionice context
3) priority cgroups
We can disable (2) and (3) and leave (1) as is.
Trying to solve this issue in mq-deadline would require keeping track of the io
priority used for a write request that is issued to a zone and use that same
priority for all following write requests for the same zone until there are no
writes pending for that zone. Otherwise, you will get the priority inversion
causing the reordering.
But I think that doing all this without also causing priority inversion for the
user, i.e. a high priority write request ends up waiting for a low priority one,
will be challenging, to say the least.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2023-12-12 23:52 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 5:32 [PATCH 0/3] Improve mq-deadline I/O priority support Bart Van Assche
2023-12-05 5:32 ` [PATCH 1/3] block/mq-deadline: Use dd_rq_ioclass() instead of open-coding it Bart Van Assche
2023-12-06 2:35 ` Damien Le Moal
2023-12-11 16:54 ` Christoph Hellwig
2023-12-05 5:32 ` [PATCH 2/3] block/mq-deadline: Introduce dd_bio_ioclass() Bart Van Assche
2023-12-06 2:35 ` Damien Le Moal
2023-12-11 16:55 ` Christoph Hellwig
2023-12-18 17:35 ` Bart Van Assche
2023-12-05 5:32 ` [PATCH 3/3] block/mq-deadline: Disable I/O prioritization in certain cases Bart Van Assche
2023-12-06 2:42 ` Damien Le Moal
2023-12-06 3:24 ` Bart Van Assche
2023-12-08 0:03 ` Bart Van Assche
2023-12-08 3:37 ` Damien Le Moal
2023-12-08 18:40 ` Bart Van Assche
2023-12-11 7:40 ` Damien Le Moal
2023-12-12 22:44 ` Bart Van Assche
2023-12-12 23:52 ` Damien Le Moal [this message]
2023-12-13 1:02 ` Bart Van Assche
2023-12-13 5:29 ` Damien Le Moal
2023-12-11 16:57 ` Christoph Hellwig
2023-12-11 17:20 ` Bart Van Assche
2023-12-12 15:40 ` Christoph Hellwig
2023-12-11 22:40 ` Damien Le Moal
2023-12-12 15:41 ` Christoph Hellwig
2023-12-12 17:15 ` Bart Van Assche
2023-12-12 17:18 ` Christoph Hellwig
2023-12-12 17:42 ` Bart Van Assche
2023-12-12 17:48 ` Christoph Hellwig
2023-12-12 18:09 ` Bart Van Assche
2023-12-12 18:13 ` Christoph Hellwig
2023-12-12 18:19 ` Bart Van Assche
2023-12-12 18:26 ` Christoph Hellwig
2023-12-12 19:03 ` Jaegeuk Kim
2023-12-12 23:44 ` Damien Le Moal
2023-12-13 16:49 ` Jaegeuk Kim
2023-12-13 22:55 ` Damien Le Moal
2023-12-13 15:56 ` Christoph Hellwig
2023-12-13 16:41 ` Jaegeuk Kim
2023-12-14 8:57 ` Christoph Hellwig
2023-12-14 17:22 ` Jaegeuk Kim
2023-12-15 1:12 ` Damien Le Moal
2023-12-15 2:03 ` Jaegeuk Kim
2023-12-15 2:20 ` Keith Busch
2023-12-15 4:49 ` Christoph Hellwig
2023-12-14 19:32 ` Bart Van Assche
2023-12-14 0:08 ` Bart Van Assche
2023-12-14 0:37 ` Damien Le Moal
2023-12-14 8:51 ` Christoph Hellwig
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=95ecba8c-9a1a-49c9-92c8-f45580bc9f95@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=linux-block@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).