On Thu, Jan 18, 2024 at 1:29 AM Bart Van Assche <bvanassche@xxxxxxx> wrote:
>
> 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?
ok. I will try to update a new version to implement these in block layer
> 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?
That's just the purpose of this commit, that is, introducing content
activity based ioprio OR the one that submitter decided
>
> Bart.
