Message ID | 20230216150701.3654894-1-dhowells@redhat.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp352743wrn; Thu, 16 Feb 2023 07:10:03 -0800 (PST) X-Google-Smtp-Source: AK7set9RZlLXeDuOPvmApxK01fICHOxT2oywRFo/JrZdi/RYfBzPHvRA4mSKn2YHoKbg9wEJcFXg X-Received: by 2002:a17:902:dac3:b0:19a:945d:e31 with SMTP id q3-20020a170902dac300b0019a945d0e31mr7938114plx.13.1676560203140; Thu, 16 Feb 2023 07:10:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676560203; cv=none; d=google.com; s=arc-20160816; b=gWjzti9OzW9dX7HsBr+DPLhS8znXOkWL/iAnf3PLP0+vRAkRcAa712zFeAVjppEl5Z /lZx1ry8nYuP9iIkrmrdiy9GMrbD7sLJLnpOI7Mij03jhR2mKrdPvdngCsak8qVCkURD R59z0IJEz8BhTHDSpUNORLEImDMDvoLQr7osjw6yH92YxN1K0Yo7ShK5aQ8somhA/ATR HqVAqkpbsmsWAQxXjdwSrO65Y8K0Y4qId9Udv+Q39AAQcPx2g/gTteqp4uIcl4cSCRg7 msHZlm61KgYFksgr2G31lS2/LFjAuo9/WueOWl8Z8E8RlaIiQWU7uMQuzyBOC3Re8Ocw 5hFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=4Zm5Dn7i1p/5BiDzjYElohEtJkvunM7mT3Q22YOMQp4=; b=azd9BsOgeU64Pga5MFzlFPbq/BmiZ/XsTJ87zb7++1jM+4DRfzk/SPgiGD9ESIdpGm IUvXd4W4+uChRzudlsGiwf3hakNcC30IJ/skc4GCxE04JvrQghqOUfAmqUuqr5IQeUMF MnLhnS/gctXn9L1BwLI9SUmcxlI6jth0Ohz9i8pr2di1UUnvMhHjdlTjXR/dDEAVTMDN kA6eAiuEHM0P579Qtkui2lIdrlKHDLMYHRUzZtofOOEYLjU7sm5a3IRSzkj0RwOWK/Gh /xahlKTVs/wKWmEGLZAXFKxtYdRJinAWI8ZvjNW0Vfnpnv36xs+jldJJ/p8763yFDWUD oJ3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BRtSDGXR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z7-20020a1709027e8700b001948f3c6fbcsi1532299pla.552.2023.02.16.07.09.50; Thu, 16 Feb 2023 07:10:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BRtSDGXR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229986AbjBPPIA (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Thu, 16 Feb 2023 10:08:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229672AbjBPPH6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Feb 2023 10:07:58 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE0772F7B2 for <linux-kernel@vger.kernel.org>; Thu, 16 Feb 2023 07:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676560033; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=4Zm5Dn7i1p/5BiDzjYElohEtJkvunM7mT3Q22YOMQp4=; b=BRtSDGXRr6OgpRJ6bYIr26yfVXPEBqRTZc31RYcD2kGiEOt+QvKc+3W/uvXS8KMOgCUsAA od3pDTDa+IZS9yqP3+6r+06OStb9tZTNWzp/3n+NmDWspY1dM/w4T84rpL++/ahf+ip5J3 zoijKIVqiL1i7GfdYe8Q6ma2F1IiWfo= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-6-iIVyHqFbOUyMy5heOHW_ZQ-1; Thu, 16 Feb 2023 10:07:09 -0500 X-MC-Unique: iIVyHqFbOUyMy5heOHW_ZQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2CAE93C14862; Thu, 16 Feb 2023 15:07:07 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E53A4010E85; Thu, 16 Feb 2023 15:07:05 +0000 (UTC) From: David Howells <dhowells@redhat.com> To: Matthew Wilcox <willy@infradead.org> Cc: David Howells <dhowells@redhat.com>, Linus Torvalds <torvalds@linux-foundation.org>, Jeff Layton <jlayton@kernel.org>, Christoph Hellwig <hch@infradead.org>, 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-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v6 0/2] mm, netfs, fscache: Stop read optimisation when folio removed from pagecache Date: Thu, 16 Feb 2023 15:06:59 +0000 Message-Id: <20230216150701.3654894-1-dhowells@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758000791311806126?= X-GMAIL-MSGID: =?utf-8?q?1758000791311806126?= |
Series |
mm, netfs, fscache: Stop read optimisation when folio removed from pagecache
|
|
Message
David Howells
Feb. 16, 2023, 3:06 p.m. UTC
Hi Willy, Is this okay by you? You said you wanted to look at the remaining uses of page_has_private(), of which there are then three after these patches, not counting folio_has_private(): arch/s390/kernel/uv.c: if (page_has_private(page)) mm/khugepaged.c: 1 + page_mapcount(page) + page_has_private(page)) { mm/migrate_device.c: extra += 1 + page_has_private(page); -- I've split the folio_has_private()/filemap_release_folio() call pair merging into its own patch, separate from the actual bugfix and pulled out the folio_needs_release() function into mm/internal.h and made filemap_release_folio() use it. I've also got rid of the bit clearances from the network filesystem evict_inode functions as they doesn't seem to be necessary. Note that the last vestiges of try_to_release_page() got swept away, so I rebased and dealt with that. One comment remained, which is removed by the first patch. David Changes: ======== ver #6) - Drop the third patch which removes a duplicate check in vmscan(). ver #5) - Rebased on linus/master. try_to_release_page() has now been entirely replaced by filemap_release_folio(), barring one comment. - Cleaned up some pairs in ext4. ver #4) - Split has_private/release call pairs into own patch. - Moved folio_needs_release() to mm/internal.h and removed open-coded version from filemap_release_folio(). - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode(). - Added experimental patch to reduce shrink_folio_list(). ver #3) - Fixed mapping_clear_release_always() to use clear_bit() not set_bit(). - Moved a '&&' to the correct line. ver #2) - Rewrote entirely according to Willy's suggestion[1]. Link: https://lore.kernel.org/r/Yk9V/03wgdYi65Lb@casper.infradead.org/ [1] Link: https://lore.kernel.org/r/164928630577.457102.8519251179327601178.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/166844174069.1124521.10890506360974169994.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/166869495238.3720468.4878151409085146764.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/1459152.1669208550@warthog.procyon.org.uk/ # v3 also Link: https://lore.kernel.org/r/166924370539.1772793.13730698360771821317.stgit@warthog.procyon.org.uk/ # v4 Link: https://lore.kernel.org/r/167172131368.2334525.8569808925687731937.stgit@warthog.procyon.org.uk/ # v5 --- %(shortlog)s %(diffstat)s David Howells (2): mm: Merge folio_has_private()/filemap_release_folio() call pairs mm, netfs, fscache: Stop read optimisation when folio removed from pagecache fs/9p/cache.c | 2 ++ fs/afs/internal.h | 2 ++ fs/cachefiles/namei.c | 2 ++ fs/ceph/cache.c | 2 ++ fs/cifs/fscache.c | 2 ++ fs/ext4/move_extent.c | 12 ++++-------- fs/splice.c | 3 +-- include/linux/pagemap.h | 16 ++++++++++++++++ mm/filemap.c | 2 ++ mm/huge_memory.c | 3 +-- mm/internal.h | 11 +++++++++++ mm/khugepaged.c | 3 +-- mm/memory-failure.c | 8 +++----- mm/migrate.c | 3 +-- mm/truncate.c | 6 ++---- mm/vmscan.c | 8 ++++---- 16 files changed, 56 insertions(+), 29 deletions(-)
Comments
On Thu, Feb 16, 2023 at 10:07 AM David Howells <dhowells@redhat.com> wrote: > > Hi Willy, > > Is this okay by you? You said you wanted to look at the remaining uses of > page_has_private(), of which there are then three after these patches, not > counting folio_has_private(): > > arch/s390/kernel/uv.c: if (page_has_private(page)) > mm/khugepaged.c: 1 + page_mapcount(page) + page_has_private(page)) { > mm/migrate_device.c: extra += 1 + page_has_private(page); > > -- > I've split the folio_has_private()/filemap_release_folio() call pair > merging into its own patch, separate from the actual bugfix and pulled out > the folio_needs_release() function into mm/internal.h and made > filemap_release_folio() use it. I've also got rid of the bit clearances > from the network filesystem evict_inode functions as they doesn't seem to > be necessary. > > Note that the last vestiges of try_to_release_page() got swept away, so I > rebased and dealt with that. One comment remained, which is removed by the > first patch. > > David > > Changes: > ======== > ver #6) > - Drop the third patch which removes a duplicate check in vmscan(). > > ver #5) > - Rebased on linus/master. try_to_release_page() has now been entirely > replaced by filemap_release_folio(), barring one comment. > - Cleaned up some pairs in ext4. > > ver #4) > - Split has_private/release call pairs into own patch. > - Moved folio_needs_release() to mm/internal.h and removed open-coded > version from filemap_release_folio(). > - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode(). > - Added experimental patch to reduce shrink_folio_list(). > > ver #3) > - Fixed mapping_clear_release_always() to use clear_bit() not set_bit(). > - Moved a '&&' to the correct line. > > ver #2) > - Rewrote entirely according to Willy's suggestion[1]. > > Link: https://lore.kernel.org/r/Yk9V/03wgdYi65Lb@casper.infradead.org/ [1] > Link: https://lore.kernel.org/r/164928630577.457102.8519251179327601178.stgit@warthog.procyon.org.uk/ # v1 > Link: https://lore.kernel.org/r/166844174069.1124521.10890506360974169994.stgit@warthog.procyon.org.uk/ # v2 > Link: https://lore.kernel.org/r/166869495238.3720468.4878151409085146764.stgit@warthog.procyon.org.uk/ # v3 > Link: https://lore.kernel.org/r/1459152.1669208550@warthog.procyon.org.uk/ # v3 also > Link: https://lore.kernel.org/r/166924370539.1772793.13730698360771821317.stgit@warthog.procyon.org.uk/ # v4 > Link: https://lore.kernel.org/r/167172131368.2334525.8569808925687731937.stgit@warthog.procyon.org.uk/ # v5 > --- > %(shortlog)s > %(diffstat)s > > David Howells (2): > mm: Merge folio_has_private()/filemap_release_folio() call pairs > mm, netfs, fscache: Stop read optimisation when folio removed from > pagecache > > fs/9p/cache.c | 2 ++ > fs/afs/internal.h | 2 ++ > fs/cachefiles/namei.c | 2 ++ > fs/ceph/cache.c | 2 ++ > fs/cifs/fscache.c | 2 ++ > fs/ext4/move_extent.c | 12 ++++-------- > fs/splice.c | 3 +-- > include/linux/pagemap.h | 16 ++++++++++++++++ > mm/filemap.c | 2 ++ > mm/huge_memory.c | 3 +-- > mm/internal.h | 11 +++++++++++ > mm/khugepaged.c | 3 +-- > mm/memory-failure.c | 8 +++----- > mm/migrate.c | 3 +-- > mm/truncate.c | 6 ++---- > mm/vmscan.c | 8 ++++---- > 16 files changed, 56 insertions(+), 29 deletions(-) > > -- > Linux-cachefs mailing list > Linux-cachefs@redhat.com > https://listman.redhat.com/mailman/listinfo/linux-cachefs > Willy, and David, Can this series move forward? This just got mentioned again [1] after Chris tested the NFS netfs patches that were merged in 6.4-rc1 [1] https://lore.kernel.org/linux-nfs/CAAmbk-f_U8CPcTQM866L572uUHdK4p5iWKnUQs4r8fkW=6RW9g@mail.gmail.com/
On Tue, May 16, 2023 at 3:29 PM David Wysochanski <dwysocha@redhat.com> wrote: > > On Thu, Feb 16, 2023 at 10:07 AM David Howells <dhowells@redhat.com> wrote: > > > > Hi Willy, > > > > Is this okay by you? You said you wanted to look at the remaining uses of > > page_has_private(), of which there are then three after these patches, not > > counting folio_has_private(): > > > > arch/s390/kernel/uv.c: if (page_has_private(page)) > > mm/khugepaged.c: 1 + page_mapcount(page) + page_has_private(page)) { > > mm/migrate_device.c: extra += 1 + page_has_private(page); > > > > -- > > I've split the folio_has_private()/filemap_release_folio() call pair > > merging into its own patch, separate from the actual bugfix and pulled out > > the folio_needs_release() function into mm/internal.h and made > > filemap_release_folio() use it. I've also got rid of the bit clearances > > from the network filesystem evict_inode functions as they doesn't seem to > > be necessary. > > > > Note that the last vestiges of try_to_release_page() got swept away, so I > > rebased and dealt with that. One comment remained, which is removed by the > > first patch. > > > > David > > > > Changes: > > ======== > > ver #6) > > - Drop the third patch which removes a duplicate check in vmscan(). > > > > ver #5) > > - Rebased on linus/master. try_to_release_page() has now been entirely > > replaced by filemap_release_folio(), barring one comment. > > - Cleaned up some pairs in ext4. > > > > ver #4) > > - Split has_private/release call pairs into own patch. > > - Moved folio_needs_release() to mm/internal.h and removed open-coded > > version from filemap_release_folio(). > > - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode(). > > - Added experimental patch to reduce shrink_folio_list(). > > > > ver #3) > > - Fixed mapping_clear_release_always() to use clear_bit() not set_bit(). > > - Moved a '&&' to the correct line. > > > > ver #2) > > - Rewrote entirely according to Willy's suggestion[1]. > > > > Link: https://lore.kernel.org/r/Yk9V/03wgdYi65Lb@casper.infradead.org/ [1] > > Link: https://lore.kernel.org/r/164928630577.457102.8519251179327601178.stgit@warthog.procyon.org.uk/ # v1 > > Link: https://lore.kernel.org/r/166844174069.1124521.10890506360974169994.stgit@warthog.procyon.org.uk/ # v2 > > Link: https://lore.kernel.org/r/166869495238.3720468.4878151409085146764.stgit@warthog.procyon.org.uk/ # v3 > > Link: https://lore.kernel.org/r/1459152.1669208550@warthog.procyon.org.uk/ # v3 also > > Link: https://lore.kernel.org/r/166924370539.1772793.13730698360771821317.stgit@warthog.procyon.org.uk/ # v4 > > Link: https://lore.kernel.org/r/167172131368.2334525.8569808925687731937.stgit@warthog.procyon.org.uk/ # v5 > > --- > > %(shortlog)s > > %(diffstat)s > > > > David Howells (2): > > mm: Merge folio_has_private()/filemap_release_folio() call pairs > > mm, netfs, fscache: Stop read optimisation when folio removed from > > pagecache > > > > fs/9p/cache.c | 2 ++ > > fs/afs/internal.h | 2 ++ > > fs/cachefiles/namei.c | 2 ++ > > fs/ceph/cache.c | 2 ++ > > fs/cifs/fscache.c | 2 ++ > > fs/ext4/move_extent.c | 12 ++++-------- > > fs/splice.c | 3 +-- > > include/linux/pagemap.h | 16 ++++++++++++++++ > > mm/filemap.c | 2 ++ > > mm/huge_memory.c | 3 +-- > > mm/internal.h | 11 +++++++++++ > > mm/khugepaged.c | 3 +-- > > mm/memory-failure.c | 8 +++----- > > mm/migrate.c | 3 +-- > > mm/truncate.c | 6 ++---- > > mm/vmscan.c | 8 ++++---- > > 16 files changed, 56 insertions(+), 29 deletions(-) > > > > -- > > Linux-cachefs mailing list > > Linux-cachefs@redhat.com > > https://listman.redhat.com/mailman/listinfo/linux-cachefs > > > > Willy, and David, > > Can this series move forward? > This just got mentioned again [1] after Chris tested the NFS netfs > patches that were merged in 6.4-rc1 > > [1] https://lore.kernel.org/linux-nfs/CAAmbk-f_U8CPcTQM866L572uUHdK4p5iWKnUQs4r8fkW=6RW9g@mail.gmail.com/ Sorry about the timing on the original email as I forgot it lined up with LSF/MM. FYI, I tested with 6.4-rc1 plus these two patches, then I added the NFS hunk needed (see below). All my tests pass now[1], and it makes sense from all the ftraces I've seen on test runs that fail (cachefiles_prep_read trace event would show "DOWN no-data" even after data was written previously). This small NFS hunk needs added to patch #2 in this series: diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c index 8c35d88a84b1..d4a20748b14f 100644 --- a/fs/nfs/fscache.c +++ b/fs/nfs/fscache.c @@ -180,6 +180,10 @@ void nfs_fscache_init_inode(struct inode *inode) &auxdata, /* aux_data */ sizeof(auxdata), i_size_read(inode)); + + if (netfs_inode(inode)->cache) + mapping_set_release_always(inode->i_mapping); + } /* [1] https://lore.kernel.org/linux-nfs/CALF+zOn_qX4tcT2ucq4jD3G-1ERqZkL6Cw7hx75OnQF0ivqSeA@mail.gmail.com/
Any update on this? I assume it's too late for these patches to make 6.4.0.