linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yu Kuai <yukuai1@huaweicloud.com>
To: Matthew Wilcox <willy@infradead.org>, Yu Kuai <yukuai1@huaweicloud.com>
Cc: axboe@kernel.dk, roger.pau@citrix.com, colyli@suse.de,
	kent.overstreet@gmail.com, joern@lazybastard.org,
	miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
	sth@linux.ibm.com, hoeppner@linux.ibm.com, hca@linux.ibm.com,
	gor@linux.ibm.com, agordeev@linux.ibm.com, jejb@linux.ibm.com,
	martin.petersen@oracle.com, clm@fb.com, josef@toxicpanda.com,
	dsterba@suse.com, nico@fluxnic.net, xiang@kernel.org,
	chao@kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca,
	agruenba@redhat.com, jack@suse.com, konishi.ryusuke@gmail.com,
	akpm@linux-foundation.org, hare@suse.de, p.raghav@samsung.com,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org,
	linux-mtd@lists.infradead.org, linux-s390@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-bcachefs@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org,
	linux-ext4@vger.kernel.org, gfs2@lists.linux.dev,
	linux-nilfs@vger.kernel.org, yi.zhang@huawei.com,
	yangerkun@huawei.com, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH -next RFC 01/14] block: add some bdev apis
Date: Thu, 7 Dec 2023 10:45:13 +0800	[thread overview]
Message-ID: <d195aba8-7b89-698f-b7a0-06b87ae01c21@huaweicloud.com> (raw)
In-Reply-To: <ZXCMJ9skAAgPm4z3@casper.infradead.org>

Hi,

在 2023/12/06 22:58, Matthew Wilcox 写道:
> On Tue, Dec 05, 2023 at 08:37:15PM +0800, Yu Kuai wrote:
>> +struct folio *bdev_read_folio(struct block_device *bdev, pgoff_t index)
>> +{
>> +	return read_mapping_folio(bdev->bd_inode->i_mapping, index, NULL);
>> +}
>> +EXPORT_SYMBOL_GPL(bdev_read_folio);
> 
> I'm coming to the opinion that 'index' is the wrong parameter here.
> Looking through all the callers of bdev_read_folio() in this patchset,
> they all have a position in bytes, and they all convert it to
> index for this call.  The API should probably be:
> 
> struct folio *bdev_read_folio(struct block_device *bdev, loff_t pos)
> {
> 	return read_mapping_folio(bdev->bd_inode->i_mapping,
> 			pos / PAGE_SIZE, NULL);
> }

Thanks for reviewing this patchset! Okay, I'll convert to pass in "pos"
in v2.
> 
> ... and at some point, we'll get round to converting read_mapping_folio()
> to take its argument in loff_t.
> 
> Similiarly for these two APIs:
> 
>> +struct folio *bdev_read_folio_gfp(struct block_device *bdev, pgoff_t index,
>> +				  gfp_t gfp)
>> +struct folio *bdev_get_folio(struct block_device *bdev, pgoff_t index)
> 
>> +struct folio *bdev_find_or_create_folio(struct block_device *bdev,
>> +					pgoff_t index, gfp_t gfp)
>> +{
>> +	return __filemap_get_folio(bdev->bd_inode->i_mapping, index,
>> +				   FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
>> +}
>> +EXPORT_SYMBOL_GPL(bdev_find_or_create_folio);
> 
> This one probably shouldn't exist.  I've been converting callers of
> find_or_create_page() to call __filemap_get_folio; I suspect we
> should expose a __bdev_get_folio and have the callers use the FGP
> arguments directly, but I'm open to other opinions here.

If nobody against this, I will expose single __bdev_get_folio() to use
in v2.
> 
>> +void bdev_sync_readahead(struct block_device *bdev, struct file_ra_state *ra,
>> +			 struct file *file, pgoff_t index,
>> +			 unsigned long req_count)
>> +{
>> +	struct file_ra_state tmp_ra = {};
>> +
>> +	if (!ra) {
>> +		ra = &tmp_ra;
>> +		file_ra_state_init(ra, bdev->bd_inode->i_mapping);
>> +	}
>> +	page_cache_sync_readahead(bdev->bd_inode->i_mapping, ra, file, index,
>> +				  req_count);
>> +}
> 
> I think the caller should always be passing in a valid file_ra_state.
> It's only cramfs that doesn't have one, and it really should!
> Not entirely sure about the arguments here; part of me says "bytes",
> but this is weird enough to maybe take arguments in pages.

In fact, bdev_sync_readahead() is only called for cramfs and ext4.

For ext4 it's used in ext4_readdir() so there is valid file_ra_state.

Hoever, for cramfs it's used in cramfs_read(), and cramfs_read() is used
for:

1) cramfs_read_folio
2) cramfs_readdir
3) cramfs_lookup
4) cramfs_read_super

Looks like it's easy to pass in valid file_ra_state() for 1) and 2),
however, I don't see an easy way to do this for 3) and 4).

Thanks,
Kuai

> 
> .
> 


  reply	other threads:[~2023-12-07  2:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 12:37 [PATCH -next RFC 00/14] block: don't access bd_inode directly from other modules Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 01/14] block: add some bdev apis Yu Kuai
2023-12-05 17:03   ` Bart Van Assche
2023-12-06  6:14   ` Christoph Hellwig
2023-12-06  6:50     ` Yu Kuai
2023-12-06  7:20       ` Christoph Hellwig
2023-12-06 17:50     ` Theodore Ts'o
2023-12-06 17:57       ` Christoph Hellwig
2023-12-06 14:58   ` Matthew Wilcox
2023-12-07  2:45     ` Yu Kuai [this message]
2023-12-05 12:37 ` [PATCH -next RFC 02/14] xen/blkback: use bdev api in xen_update_blkif_status() Yu Kuai
2023-12-06  5:55   ` Christoph Hellwig
2023-12-06  6:56     ` Yu Kuai
2023-12-06  7:21       ` Christoph Hellwig
2023-12-05 12:37 ` [PATCH -next RFC 03/14] bcache: use bdev api in read_super() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 04/14] mtd: block2mtd: use bdev apis Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 05/14] s390/dasd: use bdev api in dasd_format() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 06/14] scsicam: use bdev api in scsi_bios_ptable() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 07/14] bcachefs: remove dead function bdev_sectors() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 08/14] btrfs: use bdev apis Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 09/14] cramfs: use bdev apis in cramfs_blkdev_read() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 10/14] erofs: use bdev api Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 11/14] ext4: use bdev apis Yu Kuai
2023-12-05 12:38 ` [PATCH -next RFC 12/14] jbd2: " Yu Kuai
2023-12-05 12:39 ` [PATCH -next RFC 13/14] gfs2: use bdev api Yu Kuai
2023-12-05 12:39 ` [PATCH -next RFC 14/14] nilfs2: use bdev api in nilfs_attach_log_writer() Yu Kuai
2023-12-06  5:54 ` [PATCH -next RFC 00/14] block: don't access bd_inode directly from other modules Christoph Hellwig
2023-12-06  6:06   ` Yu Kuai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d195aba8-7b89-698f-b7a0-06b87ae01c21@huaweicloud.com \
    --to=yukuai1@huaweicloud.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=agordeev@linux.ibm.com \
    --cc=agruenba@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=chao@kernel.org \
    --cc=clm@fb.com \
    --cc=colyli@suse.de \
    --cc=dsterba@suse.com \
    --cc=gfs2@lists.linux.dev \
    --cc=gor@linux.ibm.com \
    --cc=hare@suse.de \
    --cc=hca@linux.ibm.com \
    --cc=hoeppner@linux.ibm.com \
    --cc=jack@suse.com \
    --cc=jejb@linux.ibm.com \
    --cc=joern@lazybastard.org \
    --cc=josef@toxicpanda.com \
    --cc=kent.overstreet@gmail.com \
    --cc=konishi.ryusuke@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nico@fluxnic.net \
    --cc=p.raghav@samsung.com \
    --cc=richard@nod.at \
    --cc=roger.pau@citrix.com \
    --cc=sth@linux.ibm.com \
    --cc=tytso@mit.edu \
    --cc=vigneshr@ti.com \
    --cc=willy@infradead.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiang@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).