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 E3E03C433FE for ; Tue, 15 Nov 2022 02:34:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FE1D6B0073; Mon, 14 Nov 2022 21:34:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AE9F6B0074; Mon, 14 Nov 2022 21:34:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 476BE6B0075; Mon, 14 Nov 2022 21:34:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3A0C96B0073 for ; Mon, 14 Nov 2022 21:34:58 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0BE30A03C7 for ; Tue, 15 Nov 2022 02:34:58 +0000 (UTC) X-FDA: 80134109076.23.106A67F Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by imf29.hostedemail.com (Postfix) with ESMTP id 5EF73120011 for ; Tue, 15 Nov 2022 02:34:56 +0000 (UTC) Received: by nautica.notk.org (Postfix, from userid 108) id 47863C01C; Tue, 15 Nov 2022 03:35:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1668479700; bh=nbL/xZDPCL8jmbEEnRtWHyMrAnIAlzzCW9ltmbNEdmY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BTubEyb88pK+tsFm7mlAIi0fLDfKqvqQliCRntOPeC4bJA7GiR8kUDT7tiQCWJIiS u0yKZzPzdUkxqS4ycN4tcYIjo+s5sw92WqHr8NaO7GbCjD3sgqG4vrudrxEhFOrT9f +T8bbOugd7Dg7OSLKsblTaJ9E/kMNnh6rnyRX7sIEznZDN5dyWBWm7rjvVYYPfL8Ur aGrU8o9oMCKHmT4nvvDedDxlMj92pLGNV+MnictvtnaosvsSfGqroOpH2OV3ziZ/E9 INWP10dOAk+5o4VIlIZbWsChdcJCuG+0QBDXAaLx8Rp1dTjjERzVmfrvQTLaxM64pK r7cxJX4SQt5WQ== Received: from odin.codewreck.org (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id D917EC009; Tue, 15 Nov 2022 03:34:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1668479699; bh=nbL/xZDPCL8jmbEEnRtWHyMrAnIAlzzCW9ltmbNEdmY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ODuILm6w+muG3YeYXeL/B2w4v4ALouBB7EV1VWeD79EfdWs/VXHiGECni9EG7SqsI agXPtCjW3dGG4vr5u/QKL9H6P16bSuKD0imiXCGlAD0h2CLVsb8gZ+zbmNmMIOJRTR Wv09VHJNaZty+f1IPSOoZ8PvXKpoig+0zjZjTZ2n4NhZJ2PqeRmn25Xf5lQgrMAo6M mxOKmEx83Okrxey+BEMqnxazd9KX0jdhVii/ypx6Z171SAn5mV7jqq5K5IfgQrcRqn HlAUbhC42z9d7SAJrThRyyEAOysG0Cja0bVY4Y2pkA+slZ0Jh+0maC+cdYHAkDORZO rKrJwJ3Gb50hg== Received: from localhost (odin.codewreck.org [local]) by odin.codewreck.org (OpenSMTPD) with ESMTPA id ea3428a8; Tue, 15 Nov 2022 02:34:46 +0000 (UTC) Date: Tue, 15 Nov 2022 11:34:31 +0900 From: Dominique Martinet To: David Howells Cc: willy@infradead.org, dwysocha@redhat.com, Rohith Surabattula , Steve French , Shyam Prasad N , 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: [RFC PATCH v2] mm, netfs, fscache: Stop read optimisation when folio removed from pagecache Message-ID: References: <166844174069.1124521.10890506360974169994.stgit@warthog.procyon.org.uk> <1457985.1668472862@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1457985.1668472862@warthog.procyon.org.uk> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668479696; 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=nbL/xZDPCL8jmbEEnRtWHyMrAnIAlzzCW9ltmbNEdmY=; b=hfqTFv+PrArVFlaEFnrUCGhkrSzyjs3gZhbzGJ1uJ761FV5J3xiqBb9D3QJ2y7lPPq5ZaP l01ohOSip4aXyvfvMuvPYIcuok+xD6qshKkbCN6b8FkW6UVZM9TT84u3D38ZQX4gZdkXIZ FjwM8NuJTobxGHUDYugq/3eq20njSeo= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=BTubEyb8; dkim=pass header.d=codewreck.org header.s=2 header.b=ODuILm6w; spf=pass (imf29.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org; dmarc=pass (policy=none) header.from=codewreck.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668479696; a=rsa-sha256; cv=none; b=jXbHuZ8zP4Okam9iKax8tLyLdO7z9YoWWhfN0pY8+n+sR4bsuTBiu+yAzxmuHUX19QVGPS U7jWpf4UWF7L4I2RllnkyeR9TxgTz4yZrVHCpxDQqpea3Q3rbnHK4GpGYjrOIGJiDxeD9x JMQnksmtrCHibtizLVnmzU/WN9gz/UI= X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5EF73120011 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=BTubEyb8; dkim=pass header.d=codewreck.org header.s=2 header.b=ODuILm6w; spf=pass (imf29.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org; dmarc=pass (policy=none) header.from=codewreck.org X-Stat-Signature: rmji8kun8ci9sd43ugejcqjoy5cko6g1 X-HE-Tag: 1668479696-706789 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: David Howells wrote on Tue, Nov 15, 2022 at 12:41:02AM +0000: > Dominique Martinet wrote: > > any harm in setting this if netfs isn't enabled? > > (just asking because you checked in fs/9p/cache.c above) > > Well, it forces a call to ->release_folio() every time a folio is released, if > set, rather than just if PG_private/PG_private_2 is set. Yes, that's what I gathered from your explanation, but I don't understand what release_folio() actually implies in practice which is why I asked -- it looked a bit odd that you're checking for v9inode->netfs.cache in one case and not in the other; especially as all inodes should go through both v9fs_cache_inode_get_cookie() (when created) and v9fs_evict_inode() so I was a bit curious. In the 9p-without-cache case, we're normally not going through page cache at all, so I guess there won't be any mapping and this will be free anyway... > > > - if (folio_has_private(folio) && !filemap_release_folio(folio, 0)) > > > + if (!filemap_release_folio(folio, 0)) > > > > should this (and all others) check for folio_needs_release instead of has_private? > > filemap_release_folio doesn't check as far as I can see, but perhaps > > it's already fast and noop for another reason I didn't see. > > Willy suggested merging the checks from folio_has_private() into > filemap_release_folio(): > > https://lore.kernel.org/r/Yk9V/03wgdYi65Lb@casper.infradead.org/ Ah, I didn't understand the suggestion in your patch was a separate patch and didn't follow the link. It doesn't look like a patch per se, perhaps sending both together would make sense -- but on top of this change these should indeed be fine, thanks. -- Dominique