Received-SPF: pass (google.com: domain of linux-kernel+bounces-179641-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240515012350.1166350-1-zhaoyang.huang@unisoc.com>
 <20240515012350.1166350-3-zhaoyang.huang@unisoc.com> <ZkRnCDasZNvFQUaY@slm.duckdns.org>
In-Reply-To: <ZkRnCDasZNvFQUaY@slm.duckdns.org>
From: Zhaoyang Huang <huangzhaoyang@gmail.com>
Date: Wed, 15 May 2024 16:17:32 +0800
Message-ID: <CAGWkznEbN4UFCS2LQkGMjXeFXFmDBva9pT0fTjX7+mcP2qAiLQ@mail.gmail.com>
Subject: Re: [RFC PATCH 2/2] mm: introduce budgt control in readahead
To: Tejun Heo <tj@kernel.org>
Cc: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>, Andrew Morton <akpm@linux-foundation.org>, 
	Matthew Wilcox <willy@infradead.org>, Jens Axboe <axboe@kernel.dk>, 
	Josef Bacik <josef@toxicpanda.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, linux-mm@kvack.org, 
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, 
	cgroups@vger.kernel.org, steve.kang@unisoc.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2024 at 3:40=E2=80=AFPM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Wed, May 15, 2024 at 09:23:50AM +0800, zhaoyang.huang wrote:
> > +static unsigned long get_next_ra_size(struct readahead_control *ractl,
> >                                     unsigned long max)
> >  {
> > +     unsigned long cur =3D ractl->ra->size;
> > +     struct inode *inode =3D ractl->mapping->host;
> > +     unsigned long budgt =3D inode->i_sb->s_bdev ?
> > +                     blk_throttle_budgt(inode->i_sb->s_bdev) : 0;
>
> Technical correctness aside, I'm not convinced it's generally a good idea=
 to
> bubble up one specific IO control mechanism's detail all the way upto RA
> layer. Besides what's the gain here? For continuous IO stream, whether so=
me
> RA bios are oversized or not shouldn't matter, no? Doesn't this just affe=
ct
> the accuracy of the last RA IO of a finite read stream?
Thanks for feedback. If I understand right, the oversized RA bios of a
finite read will fail by being queued to tg's queue which should be
deemed as introducing a drop of IOPS.

submit_bio
    blk_throtl_bio
        if(!tg_may_dispatch) //failed, queue the bio to tg's queue

What we get here is a more precise BW of the throttled blkcg like
below, from which we can find the result of 'after' could exactly meet
the configured bps value and a little bit enhancement since there are
no hung(oversized) bios any more.

blkio.throttle.read_bps_device =3D 20MB/s
fio ... -numjobs=3D8 ...

    before : IOPS=3D37.9k, BW=3D148MiB/s (155MB/s)(11.6GiB/80333msec)
    after  : IOPS=3D39.0k, BW=3D153MiB/s (160MB/s)(15.6GiB/104914msec)

    before : clat (usec): min=3D4, max=3D1056.6k, avg=3D197.23, stdev=3D100=
80.69
    after  : clat (usec): min=3D4, max=3D193481, avg=3D188.83, stdev=3D4651=
29

    before : lat (usec): min=3D5, max=3D1056.6k, avg=3D200.48, stdev=3D1008=
0.76
    after  : lat (usec): min=3D5, max=3D193483, avg=3D192.68, stdev=3D4651.=
87

blkio.throttle.read_bps_device =3D 30MB/s
fio ... -numjobs=3D8 ...

    before : IOPS=3D57.2k, BW=3D224MiB/s (234MB/s)(15.6GiB/71561msec)
    after  : IOPS=3D58.5k, BW=3D229MiB/s (240MB/s)(15.6GiB/69996msec)

    before : clat (usec): min=3D4, max=3D1105.5k, avg=3D126.20, stdev=3D641=
9.22
    after  : clat (usec): min=3D4, max=3D183956, avg=3D120.60, stdev=3D2957=
28

    before : lat (usec): min=3D5, max=3D1105.5k, avg=3D129.45, stdev=3D6419=
29
    after  : lat (usec): min=3D5, max=3D183958, avg=3D124.40, stdev=3D2958.=
18

>
> Thanks. blk_throttle_budgt

>
> --
> tejun