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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2539C433FE for ; Wed, 23 Nov 2022 20:03:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 170F16B0071; Wed, 23 Nov 2022 15:03:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 120596B0072; Wed, 23 Nov 2022 15:03:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F29056B0074; Wed, 23 Nov 2022 15:03:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E2DE86B0071 for ; Wed, 23 Nov 2022 15:03:15 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B2D83AA9D2 for ; Wed, 23 Nov 2022 20:03:15 +0000 (UTC) X-FDA: 80165781150.15.C1790EC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf06.hostedemail.com (Postfix) with ESMTP id 1FC02180004 for ; Wed, 23 Nov 2022 20:03:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669233792; 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: in-reply-to:in-reply-to:references:references; bh=FyF91lZbMxrHn5anVwrCryKb88DRm4Sm24TF8WqfMn8=; b=XEw1gBSxh1L4AYQJn4VsrqkpqQHl45vLr7kViDs6mJy8ZnersJybW/GejFUN5zvALFfNjZ wDiTYDyJCec+RO4UjyC3qX7CqkB4hUYPz3vbALZw7rQDwNpAQyOGZu1D+W1bqlIBHZI3VO W5teeO5V2JxxD2mcYLWOoBsL90BmJS0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-599-WfiQ4PvGNeam6muHEfvymg-1; Wed, 23 Nov 2022 15:03:09 -0500 X-MC-Unique: WfiQ4PvGNeam6muHEfvymg-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 CB7E087B2A1; Wed, 23 Nov 2022 20:03:08 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.14]) by smtp.corp.redhat.com (Postfix) with ESMTP id B49AF40C83C5; Wed, 23 Nov 2022 20:03:06 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <1459152.1669208550@warthog.procyon.org.uk> To: Linus Torvalds Cc: dhowells@redhat.com, willy@infradead.org, dwysocha@redhat.com, Rohith Surabattula , Steve French , Shyam Prasad N , Dominique Martinet , Ilya Dryomov , linux-cachefs@redhat.com, linux-cifs@vger.kernel.org, linux-afs@lists.infradead.org, v9fs-developer@lists.sourceforge.net, ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] mm, netfs, fscache: Stop read optimisation when folio removed from pagecache MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1619342.1669233783.1@warthog.procyon.org.uk> Date: Wed, 23 Nov 2022 20:03:03 +0000 Message-ID: <1619343.1669233783@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XEw1gBSx; spf=pass (imf06.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669233793; a=rsa-sha256; cv=none; b=fXmHkZmYpWpuhx2himkizDn225lg9rY5ctU3m2OW6k+SB6hK/6R3jVuCYuvI7eMNt03tLr vySSdknhuBRyVZ0qB3LLFjaJ/uUjPBuFaXrxVXXab94/qdGU9m7k6zk5M9WuBqbC2Jy+tU d1/HmS0Npx54YqhWwY6rwV/vhKiLv7Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669233793; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FyF91lZbMxrHn5anVwrCryKb88DRm4Sm24TF8WqfMn8=; b=rWmXceQwJlTYtnNVSLRcJswp89zu/E3HUBcBnnbm769q39P1SH1HwXUvDkEChaH57pqiqE ZTDxm9QB953zJC7B1rCii+RonDTL0anDFyxKm0FD/2MsHDZibSS1bpSdAVQwH9Nwuh1ESu SOOlUkNRbL213WBGuglgWuHEltyXL4E= X-Rspamd-Queue-Id: 1FC02180004 X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XEw1gBSx; spf=pass (imf06.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam06 X-Stat-Signature: mzrfp5rjxxpptx3kp3srnj573udcp484 X-HE-Tag: 1669233792-137608 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: Linus Torvalds wrote: > But I also think it's strange in another way, with that odd placement of > > mapping_clear_release_always(inode->i_mapping); > > at inode eviction time. That just feels very random. I was under the impression that a warning got splashed if unexpected address_space flags were set when ->evict_inode() returned. I may be thinking of page flags. If it doesn't, fine, this isn't required. > Similarly, that change to shrink_folio_list() looks strange, with the > nasty folio_needs_release() helper. It seems entirely pointless, with > the use then being > > if (folio_needs_release(folio)) { > if (!filemap_release_folio(folio, sc->gfp_mask)) > goto activate_locked; Unfortunately, that can't be simply folded down. It actually does something extra if folio_has_private() was set, filemap_release_folio() succeeds but there was no mapping: * Rarely, folios can have buffers and no ->mapping. * These are the folios which were not successfully * invalidated in truncate_cleanup_folio(). We try to * drop those buffers here and if that worked, and the * folio is no longer mapped into process address space * (refcount == 1) it can be freed. Otherwise, leave * the folio on the LRU so it is swappable. Possibly I could split the if-statement and make it two separate cases: /* * If the folio has buffers, try to free the buffer * mappings associated with this folio. If we succeed * we try to free the folio as well. * * We do this even if the folio is dirty. * filemap_release_folio() does not perform I/O, but it * is possible for a folio to have the dirty flag set, * but it is actually clean (all its buffers are clean). * This happens if the buffers were written out directly, * with submit_bh(). ext3 will do this, as well as * the blockdev mapping. filemap_release_folio() will * discover that cleanness and will drop the buffers * and mark the folio clean - it can be freed. */ if (!filemap_release_folio(folio, sc->gfp_mask)) goto activate_locked; filemap_release_folio() will return true if folio_has_private() is false, which would allow us to reach the next part, which we would then skip. /* * Rarely, folios can have buffers and no ->mapping. * These are the folios which were not successfully * invalidated in truncate_cleanup_folio(). We try to * drop those buffers here and if that worked, and the * folio is no longer mapped into process address space * (refcount == 1) it can be freed. Otherwise, leave * the folio on the LRU so it is swappable. */ if (!mapping && folio_has_private(folio) && folio_ref_count(folio) == 1) { folio_unlock(folio); if (folio_put_testzero(folio)) goto free_it; /* * rare race with speculative reference. * the speculative reference will free * this folio shortly, so we may * increment nr_reclaimed here (and * leave it off the LRU). */ nr_reclaimed += nr_pages; continue; } But that will malfunction if try_to_free_buffers(), as called from folio_has_private(), manages to clear the private bits. I wonder if it might be possible to fold this bit into filemap_release_folio() somehow. I really need a three-state return from filemap_release_folio() - maybe: 0 couldn't release 1 released 2 there was no private The ordinary "if (filemap_release_folio()) { ... }" would work as expected. shrink_folio_list() could do something different between case 1 and case 2. > And the change to mm/filemap.c is completely unacceptable in all > forms, and this added test > > + if ((!mapping || !mapping_release_always(mapping)) && > + !folio_test_private(folio) && > + !folio_test_private_2(folio)) > + return true; > > will not be accepted even during the merge window. That code makes no > sense what-so-ever, and is in no way acceptable. > > That code makes no sense what-so-ever. Why isn't it using > "folio_has_private()"? It should be, yes. > Why is this done as an open-coded - and *badly* so - version of > !folio_needs_release() that you for some reason made private to mm/vmscan.c? Yeah, in retrospect, I should have put that in mm/internal.h. David