linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Yu Zhao <yuzhao@google.com>,
	Niklas Cassel <niklas.cassel@wdc.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Hannes Reinecke <hare@suse.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-mm@kvack.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, steve.kang@unisoc.com
Subject: Re: [PATCHv3 1/1] block: introduce content activity based ioprio
Date: Thu, 25 Jan 2024 17:26:04 +0900	[thread overview]
Message-ID: <95082224-a61d-4f4b-bc96-1beea8aa93a9@kernel.org> (raw)
In-Reply-To: <CAGWkznHK5UPajY2PG24Jm7+A0c9q+tyQzrPdd=n3tp0dgX+T0w@mail.gmail.com>

On 1/25/24 16:52, Zhaoyang Huang wrote:
> On Thu, Jan 25, 2024 at 3:40 PM Damien Le Moal <dlemoal@kernel.org> wrote:
>>
>> On 1/25/24 16:19, zhaoyang.huang wrote:
>>> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>>>
>>> Currently, request's ioprio are set via task's schedule priority(when no
>>> blkcg configured), which has high priority tasks possess the privilege on
>>> both of CPU and IO scheduling.
>>> This commit works as a hint of original policy by promoting the request ioprio
>>> based on the page/folio's activity. The original idea comes from LRU_GEN
>>> which provides more precised folio activity than before. This commit try
>>> to adjust the request's ioprio when certain part of its folios are hot,
>>> which indicate that this request carry important contents and need be
>>> scheduled ealier.
>>>
>>> This commit is verified on a v6.6 6GB RAM android14 system via 4 test cases
>>> by changing the bio_add_page/folio API in ext4 and f2fs.
>>
>> And as mentioned already by Chrisoph and Jens, why don't you just simply set
>> bio->bi_ioprio to the value you want before calling submit_bio() in these file
>> systems ? Why all the hacking of the priority code for that ? That is not
>> justified at all.
>>
>> Furthermore, the activity things reduces the ioprio hint bits to the bare
>> minimum 3 bits necessary for command duration limits. Not great. But if you
>> simply set the prio class based on your activity algorithm, you do not need to
>> change all that.
> That is because bio->io_prio changes during bio grows with adding
> different activity pages in. I have to wrap these into an API which
> has both of fs and block be transparent to the process.

Pages are not added to BIOs on the fly. The FS does bio_add_page() or similar
(it can be a get user pages for direct IOs) and then calls bio_submit(). Between
these 2, you can set your IO priority according to how many pages you have.

You can even likely do all of this based on the iocb (and use iocb->ki_ioprio to
set the prio), so before one starts allocating and setting up BIOs to process
the user IO.

-- 
Damien Le Moal
Western Digital Research



  reply	other threads:[~2024-01-25  8:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25  7:19 zhaoyang.huang
2024-01-25  7:40 ` Damien Le Moal
2024-01-25  7:52   ` Zhaoyang Huang
2024-01-25  8:26     ` Damien Le Moal [this message]
2024-01-25  9:32       ` Zhaoyang Huang
2024-01-25  9:37         ` Zhaoyang Huang
2024-01-25  9:54           ` Damien Le Moal
2024-01-25 10:10             ` Zhaoyang Huang
2024-01-26  1:14               ` Zhaoyang Huang
2024-01-26  7:59 ` Zhaoyang Huang
2024-01-26  8:55   ` Matthew Wilcox
2024-01-26  9:28     ` Zhaoyang Huang
2024-01-26  9:36       ` Matthew Wilcox
2024-01-26  9:49         ` Zhaoyang Huang

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=95082224-a61d-4f4b-bc96-1beea8aa93a9@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.de \
    --cc=huangzhaoyang@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=martin.petersen@oracle.com \
    --cc=niklas.cassel@wdc.com \
    --cc=steve.kang@unisoc.com \
    --cc=yuzhao@google.com \
    --cc=zhaoyang.huang@unisoc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox