From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EF8AFC433FE for ; Wed, 20 Oct 2021 10:20:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A037661372 for ; Wed, 20 Oct 2021 10:20:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A037661372 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DE56C6B0071; Wed, 20 Oct 2021 06:20:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D95126B0072; Wed, 20 Oct 2021 06:20:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAB056B0073; Wed, 20 Oct 2021 06:20:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id BC70A6B0071 for ; Wed, 20 Oct 2021 06:20:44 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 82EB82D018 for ; Wed, 20 Oct 2021 10:20:44 +0000 (UTC) X-FDA: 78716422008.25.A35A5BF Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf02.hostedemail.com (Postfix) with ESMTP id DC9C47001776 for ; Wed, 20 Oct 2021 10:20:41 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 97FB761004; Wed, 20 Oct 2021 10:20:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634725243; bh=ToTI2rY165RFMu+JGNDdrfJTc77awcVma/hprClzxwk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=YiTTLo7FHRIGC5SI0BimIMnOFy4lDO7rGRhJ2LBYskUpXnJe109XRTSqZ6v1rNAky JKAP9ULv+Ppbt5IY2D2//ThMXfE8tDazy1fh96Jsw1KIYGK1PfP75EZc1Dy1Du9tqF rKTj/b4zkU2yqVF1Pbxtg0h4FbQazgMiPXx2/PT/dpRKIsxuHA4Glp4bf02RchCGdj xAcVmiEiI4ekAG+HhuYhnL6bfVLkpw35ckNrLunUqnS6W/DdbTzAH0+CFnlWT8jONq /ROw9Ltr5LlVBmkdTTApM15N+PR6MnrJO9ffsvmqPIO9zF/TDBUYHLiIInSI+jXHTU jkWD/vl1ZlG+w== Message-ID: <6226035fc82495f7ba298659d9e658e0df7bcb47.camel@kernel.org> Subject: Re: [PATCH v2] mm: Stop filemap_read() from grabbing a superfluous page From: Jeff Layton To: David Howells , kent.overstreet@gmail.com, willy@infradead.org Cc: Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 20 Oct 2021 06:20:41 -0400 In-Reply-To: <163472463105.3126792.7056099385135786492.stgit@warthog.procyon.org.uk> References: <163472463105.3126792.7056099385135786492.stgit@warthog.procyon.org.uk> Content-Type: text/plain; charset="ISO-8859-15" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DC9C47001776 X-Stat-Signature: 6jgbfmb1jowo9a3msu1i6t6njitz4787 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YiTTLo7F; spf=pass (imf02.hostedemail.com: domain of jlayton@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1634725241-355577 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 2021-10-20 at 11:10 +0100, David Howells wrote: > Under some circumstances, filemap_read() will allocate sufficient pages to > read to the end of the file, call readahead/readpages on them and copy the > data over - and then it will allocate another page at the EOF and call > readpage on that and then ignore it. This is unnecessary and a waste of > time and resources. > > filemap_read() *does* check for this, but only after it has already done > the allocation and I/O. Fix this by checking before calling > filemap_get_pages() also. > > Changes: > v2) Break out of the loop immediately rather than going to put_pages (the > pvec is unoccupied). Setting isize is then unnecessary. > > Signed-off-by: David Howells > cc: Kent Overstreet > cc: Matthew Wilcox (Oracle) > cc: Andrew Morton > cc: Jeff Layton > cc: linux-mm@kvack.org > cc: linux-fsdevel@vger.kernel.org > Link: https://lore.kernel.org/r/160588481358.3465195.16552616179674485179.stgit@warthog.procyon.org.uk/ > Link: https://lore.kernel.org/r/163456863216.2614702.6384850026368833133.stgit@warthog.procyon.org.uk/ > --- > > mm/filemap.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/filemap.c b/mm/filemap.c > index dae481293b5d..e50be519f6a4 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2625,6 +2625,9 @@ ssize_t filemap_read(struct kiocb *iocb, struct iov_iter *iter, > if ((iocb->ki_flags & IOCB_WAITQ) && already_read) > iocb->ki_flags |= IOCB_NOWAIT; > > + if (unlikely(iocb->ki_pos >= i_size_read(inode))) > + break; > + > error = filemap_get_pages(iocb, iter, &pvec); > if (error < 0) > break; > > Even better. Acked-by: Jeff Layton