[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ff36535-7cd3-4e8f-a477-9d2a98d18dd9@acm.org>
Date: Wed, 17 Jan 2024 09:29:44 -0800
From: Bart Van Assche <bvanassche@....org>
To: "zhaoyang.huang" <zhaoyang.huang@...soc.com>, Jens Axboe
<axboe@...nel.dk>, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, Zhaoyang Huang <huangzhaoyang@...il.com>,
steve.kang@...soc.com
Subject: Re: [RFC PATCH 1/1] block: introduce activity based ioprio
On 1/17/24 01:23, zhaoyang.huang wrote:
> +static enum dd_prio dd_req_ioprio(struct request *rq)
> +{
> + enum dd_prio prio;
> + const u8 ioprio_class = dd_rq_ioclass(rq);
> +#ifdef CONFIG_ACTIVITY_BASED_IOPRIO
> + struct bio *bio;
> + struct bio_vec bv;
> + struct bvec_iter iter;
> + struct page *page;
> + int gen = 0;
> + int cnt = 0;
> +
> + if (req_op(rq) == REQ_OP_READ) {
> + __rq_for_each_bio(bio, rq) {
> + bio_for_each_bvec(bv, bio, iter) {
> + page = bv.bv_page;
> + gen += PageWorkingset(page) ? 1 : 0;
> + cnt++;
> + }
> + }
> + prio = (gen >= cnt / 2) ? ioprio_class_to_prio[IOPRIO_CLASS_RT] :
> + ioprio_class_to_prio[ioprio_class];
> + } else
> + prio = ioprio_class_to_prio[ioprio_class];
> +#else
> + prio = ioprio_class_to_prio[ioprio_class];
> +#endif
> + return prio;
> +}
I don't like it that code is introduced in the mq-deadline scheduler
that accesses page cache information. Isn't that a layering violation?
Additionally, this approach only works for buffered I/O and not for
direct I/O. Shouldn't the I/O submitter set the I/O priority instead of
deciding the I/O priority in the mq-deadline scheduler?
Bart.
Powered by blists - more mailing lists