On 5/29/18 3:59 PM, Andrew Morton wrote: > On Tue, 29 May 2018 08:36:41 -0600 Jens Axboe <axboe@xxxxxxxxx> wrote: > >> On 5/24/18 1:43 PM, Andrew Morton wrote: >>> On Thu, 24 May 2018 10:02:52 -0600 Jens Axboe <axboe@xxxxxxxxx> 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 <axboe@xxxxxxxxx> >>>> --- >>>> 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? That's what I thought to, so already prepped the series. Sending it out. -- Jens Axboe
