linux-kernel - Re: [RFC PATCH 2/2] mm: introduce budgt control in readahead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 10 May 2024 15:08:16 +0800
From: Zhaoyang Huang <huangzhaoyang@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>, "zhaoyang.huang" <zhaoyang.huang@...soc.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>, 
	Josef Bacik <josef@...icpanda.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>, linux-mm@...ck.org, 
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, 
	cgroups@...r.kernel.org, steve.kang@...soc.com
Subject: Re: [RFC PATCH 2/2] mm: introduce budgt control in readahead

On Fri, May 10, 2024 at 12:14 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Fri, May 10, 2024 at 11:06:14AM +0800, Zhaoyang Huang wrote:
> > On Thu, May 9, 2024 at 8:40 PM Christoph Hellwig <hch@...radeadorg> wrote:
> > >
> > > > +     unsigned long budgt = inode->i_sb->s_bdev ?
> > > > +                     blk_throttle_budgt(inode->i_sb->s_bdev) : 0;
> > >
> > > The readahead code is used for all file systems, you can't just call
> > > into block layer code here.
> > >
> > ok. I would like to know any suggestions on introducing throttle
> > budget control into readahead which actually works as a negative
> > feedback path. IMO, negative feedback is a good methodology which has
> > been used in scheduler(EAS) and thermal control(IPA) and
> > memory(MGLRU). I would like to suggest to have a try on have it work
> > cross the boundary of memory and block layer.
> >
> > vfs_read / page fault
> > |
> > readahead  <---------|
> > |                               |
> > aops->readpages    |
> > |                               |
> > block_layer------------
>
> what you could do is have blk-throttle fail bios that are tagged as
> readahead if we've hit the threshold?
Actually, blk throttle will postpone the over-size bio's launch by
adding it to the throttle group's private queue which this idea aims
at. The delay here could be avoidable by some means to have the bio
meet the max ability of the throttle blkcg. Furthermore, we may get a
totally non over-sized readahead mechanism if we do this well.