Received-SPF: pass (google.com: domain of linux-kernel+bounces-58959-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240208093136.178797-1-zhaoyang.huang@unisoc.com>
 <20240208093136.178797-3-zhaoyang.huang@unisoc.com> <ca00ff75-e98d-4652-9c52-94b2e876901e@kernel.dk>
 <CAGWkznH6Y8u7PsoHWid0uQ+ceRK_qzSn6=eWn4dvDhK+DzSXzg@mail.gmail.com>
 <da41bac4-015f-4df0-b8cc-6c8b2f468e12@kernel.dk> <CAGWkznGnyPXM_DyyUxxZFoW=3K0B3Nh8sRZ8Lnsvm7WfES_fmA@mail.gmail.com>
 <e4078b85-5675-4fdb-a01f-7112342ec501@kernel.org>
In-Reply-To: <e4078b85-5675-4fdb-a01f-7112342ec501@kernel.org>
From: Zhaoyang Huang <huangzhaoyang@gmail.com>
Date: Fri, 9 Feb 2024 11:08:40 +0800
Message-ID: <CAGWkznFRTKmqH1Y6sQ=9dbK2q0LfJ5VEzba2Y7rsy01HWVqJZg@mail.gmail.com>
Subject: Re: [PATCH 3/3] block: introducing a bias over deadline's fifo_time
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, "zhaoyang.huang" <zhaoyang.huang@unisoc.com>, 
	Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, 
	Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 
	Yu Zhao <yuzhao@google.com>, linux-block@vger.kernel.org, 
	linux-kernel@vger.kernel.org, steve.kang@unisoc.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 9, 2024 at 9:58=E2=80=AFAM Damien Le Moal <dlemoal@kernel.org> =
wrote:
>
> On 2/9/24 09:28, Zhaoyang Huang wrote:
> > On Fri, Feb 9, 2024 at 8:11=E2=80=AFAM Jens Axboe <axboe@kernel.dk> wro=
te:
> >>
> >> On 2/8/24 5:02 PM, Zhaoyang Huang wrote:
> >>> On Fri, Feb 9, 2024 at 1:49?AM Jens Axboe <axboe@kernel.dk> wrote:
> >>>>
> >>>> On 2/8/24 2:31 AM, zhaoyang.huang wrote:
> >>>>> diff --git a/block/mq-deadline.c b/block/mq-deadline.c
> >>>>> index f958e79277b8..43c08c3d6f18 100644
> >>>>> --- a/block/mq-deadline.c
> >>>>> +++ b/block/mq-deadline.c
> >>>>> @@ -15,6 +15,7 @@
> >>>>>  #include <linux/compiler.h>
> >>>>>  #include <linux/rbtree.h>
> >>>>>  #include <linux/sbitmap.h>
> >>>>> +#include "../kernel/sched/sched.h"
> >>>>>
> >>>>>  #include <trace/events/block.h>
> >>>>>
> >>>>> @@ -802,6 +803,7 @@ static void dd_insert_request(struct blk_mq_hw_=
ctx *hctx, struct request *rq,
> >>>>>       u8 ioprio_class =3D IOPRIO_PRIO_CLASS(ioprio);
> >>>>>       struct dd_per_prio *per_prio;
> >>>>>       enum dd_prio prio;
> >>>>> +     int fifo_expire;
> >>>>>
> >>>>>       lockdep_assert_held(&dd->lock);
> >>>>>
> >>>>> @@ -840,7 +842,9 @@ static void dd_insert_request(struct blk_mq_hw_=
ctx *hctx, struct request *rq,
> >>>>>               /*
> >>>>>                * set expire time and add to fifo list
> >>>>>                */
> >>>>> -             rq->fifo_time =3D jiffies + dd->fifo_expire[data_dir]=
;
> >>>>> +             fifo_expire =3D task_is_realtime(current) ? dd->fifo_=
expire[data_dir] :
> >>>>> +                     CFS_PROPORTION(current, dd->fifo_expire[data_=
dir]);
> >>>>> +             rq->fifo_time =3D jiffies + fifo_expire;
> >>>>>               insert_before =3D &per_prio->fifo_list[data_dir];
> >>>>>  #ifdef CONFIG_BLK_DEV_ZONED
> >>>>>               /*
> >>>>
> >>>> Hard pass on this blatant layering violation. Just like the priority
> >>>> changes, this utterly fails to understand how things are properly
> >>>> designed.
> >>> IMHO, I don't think this is a layering violation. bio_set_ioprio is
> >>> the one which introduces the scheduler thing into the block layer,
> >>> this commit just wants to do a little improvement based on that. This
> >>> commit helps CFS task save some IO time when preempted by RT heavily.
> >>
> >> Listen, both this and the previous content ioprio thing show a glaring
> >> misunderstanding of how to design these kinds of things. You have no
> >> grasp of what the different layers do, or how they interact. I'm not
> >> sure how to put this kindly, but it's really an awful idea to hardcore
> >> some CFS helper into the IO scheduler. The fact that you had to fiddle
> >> around with headers to make it work was the first warning sign, and th=
e
> >> fact that you didn't stop at that point to consider how it could be
> >> properly done makes it even worse.
> >>
> >> You need to stop sending kernel patches until you understand basic
> >> software design. Neither of these patches are going anywhere until thi=
s
> >> happens. There's been plenty of feedback to telling you that, but you
> >> seem to just ignore it and plow on ahead. Stop.
> > Ok, thanks for pointing this out, I will follow your advice. But I
> > have to say that '[PATCHv9 1/1] block: introduce content activity
> > based ioprio' really solved layering violation things. I would like to
> > humbly ask for your kindly patient to have a look, as it is really
> > helpful.
>
> If properly designed, that patch would *not* be a block layer API/functio=
n and
> so does not need review by block layer folks/Jens as it would simply set =
an IO
> prio for a BIO issued by an FS. So that patch needs to be accepted by FS
> people, for the FS you are interested in.
Thanks for the heads-up, sorry for my none-sense on the needs of
maintaining the whole framework. IMHO, the newly introduced API is a
little bit like bio_set_pages_dirty which is mainly related to bio and
the pages inside. Patchv9 has changed a lot to meet your kind advice.
I would be grateful to you if you could review it.
>
>
> --
> Damien Le Moal
> Western Digital Research
>