From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:42754 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967656AbeE2V7g (ORCPT ); Tue, 29 May 2018 17:59:36 -0400 Date: Tue, 29 May 2018 14:59:35 -0700 From: Andrew Morton To: Jens Axboe Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk Subject: Re: [PATCH 1/3] mpage: mpage_readpages() should submit IO as read-ahead Message-Id: <20180529145935.a4f6d2487eb2c444ca8cc595@linux-foundation.org> In-Reply-To: <8cdea5ed-c3ef-f4f3-edea-208ebc9b45ca@kernel.dk> References: <1527177774-21414-1-git-send-email-axboe@kernel.dk> <1527177774-21414-2-git-send-email-axboe@kernel.dk> <20180524124306.1d8833f06366fcad29506182@linux-foundation.org> <8cdea5ed-c3ef-f4f3-edea-208ebc9b45ca@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 29 May 2018 08:36:41 -0600 Jens Axboe wrote: > On 5/24/18 1:43 PM, Andrew Morton wrote: > > On Thu, 24 May 2018 10:02:52 -0600 Jens Axboe wrote: > > > >> a_ops->readpages() is only ever used for read-ahead, yet we don't > >> flag the IO being submitted as such. Fix that up. Any file system > >> that uses mpage_readpages() as it's ->readpages() implementation > >> will now get this right. > >> > >> Signed-off-by: Jens Axboe > >> --- > >> fs/mpage.c | 17 +++++++++-------- > >> 1 file changed, 9 insertions(+), 8 deletions(-) > >> > >> diff --git a/fs/mpage.c b/fs/mpage.c > >> index b7e7f570733a..0a5474237f5e 100644 > >> --- a/fs/mpage.c > >> +++ b/fs/mpage.c > >> @@ -146,7 +146,7 @@ static struct bio * > >> do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages, > >> sector_t *last_block_in_bio, struct buffer_head *map_bh, > >> unsigned long *first_logical_block, get_block_t get_block, > >> - gfp_t gfp) > >> + gfp_t gfp, bool is_readahead) > > > > That's a lot of arguments. > > > > I suspect we'll have a faster kernel if we mark this __always_inline. > > I think my ancient "This isn't called much at all" over > > mpage_readpage() remains true. Almost all callers come in via > > mpage_readpages(), which would benefit from the inlining. But mpage.o > > gets 1.5k fatter. hm. > > Was going to send out a v2, but would be nice to get some consensus on > what you prefer here. I can either do the struct version, or I can > keep it as-is (going from 8 to 9 arguments). For the struct version, > I'd prefer to do that as a prep patch, so the functional change is > clear. The struct thing makes the code smaller, and presumably faster, doesn't it? I suppose it saves a bit of stack as well, by letting the callee access the caller's locals rather than a copy of them. All sounds good to me?