Message ID | 20200720075148.172156-5-hch@lst.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [01/14] fs: remove the unused SB_I_MULTIROOT flag | expand |
Hello Chrstoph, On Mon, Jul 20, 2020 at 9:53 AM Christoph Hellwig <hch@lst.de> wrote: > > Set up a readahead size by default. This changes behavior for mtd, > ubifs, and vboxsf to actually enabled readahead, the lack of which > very much looks like an oversight. UBIFS doesn't enable readahead on purpose, please see: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_readahead
On Mon, Jul 20, 2020 at 01:58:22PM +0200, Richard Weinberger wrote: > Hello Chrstoph, > > On Mon, Jul 20, 2020 at 9:53 AM Christoph Hellwig <hch@lst.de> wrote: > > > > Set up a readahead size by default. This changes behavior for mtd, > > ubifs, and vboxsf to actually enabled readahead, the lack of which > > very much looks like an oversight. > > UBIFS doesn't enable readahead on purpose, please see: > http://www.linux-mtd.infradead.org/doc/ubifs.html#L_readahead What about jffs2 and blk2mtd raw block devices?
On Mon, 2020-07-20 at 14:07 +0200, Christoph Hellwig wrote:
> What about jffs2 and blk2mtd raw block devices?
If my memory serves me correctly JFFS2 did not mind readahead.
On Mon, Jul 20, 2020 at 2:37 PM Artem Bityutskiy <dedekind1@gmail.com> wrote: > > On Mon, 2020-07-20 at 14:07 +0200, Christoph Hellwig wrote: > > What about jffs2 and blk2mtd raw block devices? I don't worry much about blk2mtd. > If my memory serves me correctly JFFS2 did not mind readahead. This covers my knowledge too. I fear enabling readahead on JFFS2 will cause performance issues, this filesystem is mostly used on small and slow NOR devices.
On Mon, Jul 20, 2020 at 11:27:57PM +0200, Richard Weinberger wrote: > On Mon, Jul 20, 2020 at 2:37 PM Artem Bityutskiy <dedekind1@gmail.com> wrote: > > > > On Mon, 2020-07-20 at 14:07 +0200, Christoph Hellwig wrote: > > > What about jffs2 and blk2mtd raw block devices? > > I don't worry much about blk2mtd. > > > If my memory serves me correctly JFFS2 did not mind readahead. > > This covers my knowledge too. > I fear enabling readahead on JFFS2 will cause performance issues, this > filesystem > is mostly used on small and slow NOR devices. I'm going to wait for Hans for feedback on vboxsf, but in doubt I'll ust add a prep patch or fold for this one to explicit set ra_pages to 0 with a comment then.
diff --git a/block/blk-core.c b/block/blk-core.c index 93104c7470e8ac..ea1665de7a2079 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -538,7 +538,6 @@ struct request_queue *blk_alloc_queue(int node_id) if (!q->stats) goto fail_stats; - q->backing_dev_info->ra_pages = VM_READAHEAD_PAGES; q->backing_dev_info->capabilities = BDI_CAP_CGROUP_WRITEBACK; q->node = node_id; diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c index 74df32be4c6a52..a338eb979cadf9 100644 --- a/fs/9p/vfs_super.c +++ b/fs/9p/vfs_super.c @@ -80,8 +80,8 @@ v9fs_fill_super(struct super_block *sb, struct v9fs_session_info *v9ses, if (ret) return ret; - if (v9ses->cache) - sb->s_bdi->ra_pages = VM_READAHEAD_PAGES; + if (!v9ses->cache) + sb->s_bdi->ra_pages = 0; sb->s_flags |= SB_ACTIVE | SB_DIRSYNC; if (!v9ses->cache) diff --git a/fs/afs/super.c b/fs/afs/super.c index b552357b1d1379..3a40ee752c1e3f 100644 --- a/fs/afs/super.c +++ b/fs/afs/super.c @@ -456,7 +456,6 @@ static int afs_fill_super(struct super_block *sb, struct afs_fs_context *ctx) ret = super_setup_bdi(sb); if (ret) return ret; - sb->s_bdi->ra_pages = VM_READAHEAD_PAGES; /* allocate the root inode and dentry */ if (as->dyn_root) { diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index eb5f2506cede72..67677207d1647d 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3031,7 +3031,6 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device } sb->s_bdi->capabilities |= BDI_CAP_CGROUP_WRITEBACK; - sb->s_bdi->ra_pages = VM_READAHEAD_PAGES; sb->s_bdi->ra_pages *= btrfs_super_num_devices(disk_super); sb->s_bdi->ra_pages = max(sb->s_bdi->ra_pages, SZ_4M / PAGE_SIZE); diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 5b4aebf5821fea..84fe187eb64385 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -1037,7 +1037,6 @@ static int fuse_bdi_init(struct fuse_conn *fc, struct super_block *sb) if (err) return err; - sb->s_bdi->ra_pages = VM_READAHEAD_PAGES; /* fuse does it's own writeback accounting */ sb->s_bdi->capabilities = BDI_CAP_NO_ACCT_WB | BDI_CAP_STRICTLIMIT; diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 7a70287f21a2c1..f943e37853fa25 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1200,13 +1200,6 @@ static void nfs_get_cache_cookie(struct super_block *sb, } #endif -static void nfs_set_readahead(struct backing_dev_info *bdi, - unsigned long iomax_pages) -{ - bdi->ra_pages = VM_READAHEAD_PAGES; - bdi->io_pages = iomax_pages; -} - int nfs_get_tree_common(struct fs_context *fc) { struct nfs_fs_context *ctx = nfs_fc2context(fc); @@ -1251,7 +1244,7 @@ int nfs_get_tree_common(struct fs_context *fc) MINOR(server->s_dev)); if (error) goto error_splat_super; - nfs_set_readahead(s->s_bdi, server->rpages); + s->s_bdi->io_pages = server->rpages; server->super = s; } diff --git a/mm/backing-dev.c b/mm/backing-dev.c index 8e8b00627bb2d8..3e441e0ff1bc88 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -746,6 +746,7 @@ struct backing_dev_info *bdi_alloc(int node_id) kfree(bdi); return NULL; } + bdi->ra_pages = VM_READAHEAD_PAGES; return bdi; } EXPORT_SYMBOL(bdi_alloc);
Set up a readahead size by default. This changes behavior for mtd, ubifs, and vboxsf to actually enabled readahead, the lack of which very much looks like an oversight. Signed-off-by: Christoph Hellwig <hch@lst.de> --- block/blk-core.c | 1 - fs/9p/vfs_super.c | 4 ++-- fs/afs/super.c | 1 - fs/btrfs/disk-io.c | 1 - fs/fuse/inode.c | 1 - fs/nfs/super.c | 9 +-------- mm/backing-dev.c | 1 + 7 files changed, 4 insertions(+), 14 deletions(-)