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 452AAC43217 for ; Tue, 19 Oct 2021 17:13:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D945261361 for ; Tue, 19 Oct 2021 17:13:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D945261361 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 19E5C900002; Tue, 19 Oct 2021 13:13:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14F0E6B007B; Tue, 19 Oct 2021 13:13:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01640900002; Tue, 19 Oct 2021 13:13:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id E28706B0078 for ; Tue, 19 Oct 2021 13:13:08 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8C444183F6A47 for ; Tue, 19 Oct 2021 17:13:08 +0000 (UTC) X-FDA: 78713832456.35.E4023BA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 6813EB000189 for ; Tue, 19 Oct 2021 17:13:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634663587; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4i8IYWG9Vqjc7NrxHtrIVVcfleXY1klKtzfa0ewfz4w=; b=gCwv+PqV7NJfQgAG0eVDmGkuM3HW+5uSYXJbWK5MCwk5Vbt85RxTazvEo6NGuzc4tJxOK4 DpcrvPUl8kljKr99KkE/01KuiZj59w/L5pG7UsKpWlJ69uDq7mNxdvDT/VSpFNlk8KbV+7 SNvICqWKMDTILFgEFIR/u+CdFy4IzfQ= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-593-e7p7hpTuNaWE3Bpjo21UTw-1; Tue, 19 Oct 2021 13:13:06 -0400 X-MC-Unique: e7p7hpTuNaWE3Bpjo21UTw-1 Received: by mail-qv1-f71.google.com with SMTP id ey7-20020a0562140b6700b00382cf3eb480so443180qvb.22 for ; Tue, 19 Oct 2021 10:13:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=4i8IYWG9Vqjc7NrxHtrIVVcfleXY1klKtzfa0ewfz4w=; b=S263f5wez7cypVtOeimCm+PnYLNSusYEENcoJY2PQaksANCDfOBqCb/OyWw2wPU0D2 /Cme1wXlZLNVlq50Uvy5ELUDZJcz6xcIQDuu2OEUKnFX/gz81DadPjz9AUYkTvT0p7Sf ehdkoGBowE0KnBCSWtAFP+Za1FpfhAnSeWtJK2C2kNIVBT9FGFVELIpm86BZOBg+kW4C QAfx++H5gd4BXdkZBexOi+KofjJfW15MChFZA8dRaBNm0iXggaXGyd8TenyEAViDQwJE 4bqtVCcGO/SHebZZiTxP15q5HK50TJzGGVYgrkFpd1zqbrWZ6qpp2EHXDdYNyQpKa3ja TULw== X-Gm-Message-State: AOAM532C5xn+hwmIy0jtFLrpvA5w5+iYIwHVbugCskm1kws1VwWALC2u vaHv2FrfYvtbTLd8ScfKFig9Ctrhvo6hKin5IZPMh6EGO9MsupOj9mY9B0saV6Aurw2wlKtSpdj zyGM8GTsj+Cw= X-Received: by 2002:ac8:59ce:: with SMTP id f14mr1309293qtf.418.1634663585804; Tue, 19 Oct 2021 10:13:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCTLnI4O14CVDS0WnTvhZl4wAoj8tNDS3DFRVR0xteRC6rTs30rKL1ujbd9t4swW1RKTIeyw== X-Received: by 2002:ac8:59ce:: with SMTP id f14mr1309267qtf.418.1634663585628; Tue, 19 Oct 2021 10:13:05 -0700 (PDT) Received: from [192.168.1.3] (68-20-15-154.lightspeed.rlghnc.sbcglobal.net. [68.20.15.154]) by smtp.gmail.com with ESMTPSA id s203sm8190618qke.21.2021.10.19.10.13.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 10:13:05 -0700 (PDT) Message-ID: Subject: Re: [PATCH 01/67] mm: Stop filemap_read() from grabbing a superfluous page From: Jeff Layton To: David Howells , linux-cachefs@redhat.com Cc: Kent Overstreet , "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Alexander Viro , Omar Sandoval , Linus Torvalds , linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Date: Tue, 19 Oct 2021 13:13:04 -0400 In-Reply-To: <163456863216.2614702.6384850026368833133.stgit@warthog.procyon.org.uk> References: <163456861570.2614702.14754548462706508617.stgit@warthog.procyon.org.uk> <163456863216.2614702.6384850026368833133.stgit@warthog.procyon.org.uk> User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gCwv+PqV; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf25.hostedemail.com: domain of jlayton@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=jlayton@redhat.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6813EB000189 X-Stat-Signature: hze1ocgk1rwqkd31ceuapty57mscixoq X-HE-Tag: 1634663584-983339 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 Mon, 2021-10-18 at 15:50 +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. > > Signed-off-by: David Howells > Acked-by: Kent Overstreet > cc: Matthew Wilcox (Oracle) > 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/ > --- > > mm/filemap.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/filemap.c b/mm/filemap.c > index dae481293b5d..c0cdc44c844e 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2625,6 +2625,10 @@ ssize_t filemap_read(struct kiocb *iocb, struct iov_iter *iter, > if ((iocb->ki_flags & IOCB_WAITQ) && already_read) > iocb->ki_flags |= IOCB_NOWAIT; > > + isize = i_size_read(inode); > + if (unlikely(iocb->ki_pos >= isize)) > + goto put_pages; > + > error = filemap_get_pages(iocb, iter, &pvec); > if (error < 0) > break; > > I would wager that it's worth checking for this. I imagine read calls beyond EOF are common enough that it's probably helpful to optimize that case: Acked-by: Jeff Layton