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 X-Spam-Level: X-Spam-Status: No, score=-4.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCA03C433E7 for ; Wed, 14 Oct 2020 16:01:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E2DD20B1F for ; Wed, 14 Oct 2020 16:01:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=aol.com header.i=@aol.com header.b="IGmrltnF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E2DD20B1F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=aol.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8BD6F940007; Wed, 14 Oct 2020 12:01:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86E626B0072; Wed, 14 Oct 2020 12:01:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 786C3940007; Wed, 14 Oct 2020 12:01:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 48E0D6B0070 for ; Wed, 14 Oct 2020 12:01:56 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 23E043625 for ; Wed, 14 Oct 2020 16:01:55 +0000 (UTC) X-FDA: 77370996990.22.fall26_080e90f2720d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 25C3018038E96 for ; Wed, 14 Oct 2020 16:01:49 +0000 (UTC) X-HE-Tag: fall26_080e90f2720d X-Filterd-Recvd-Size: 6049 Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Wed, 14 Oct 2020 16:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1602691307; bh=/sK8vKP+HgENJ2KbRKwaakALG1IJ7NVFbxhkXwQJZJ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=IGmrltnFkLJW4X3YjPlHdbMMSg3inRjB+IVV0cntt57Z3SF5t38Hz+pWqEUDjkio0/nBDPxWGlvrNUsZ6b7I7ToCTgdaNLIXe3uS/LmnXgIHFypH2p5uKig7OoGO+N01YJQfzkydaCJGNX8UmMtqW1VH+chGBGo/RP+Ny0fH3zndFDvRGMIcdbeCXZRzqG+wOG/02Z0xIij3Pfs7ovkQblF4vZzRZ+jckpLJKFqw14FxZLkXPwpH1Mnke3w8MGKraLAuop0INJyBJ7Av/FPi/KF23VOl0TXtQe8dy4qNg/j/S+TENEaPRObTapcWZ0eRYwR9n2Arkweu8Z955PoCNQ== X-YMail-OSG: FpHCXvYVM1lCRnikmgMsWcgjZPs9SMDHhpdzsqUOtxcVVgBddGNuM20bH2_RzJ_ zvsQvmdmdkGjkCtJkZB062qix1bGPhS1IofA1HCMuK3dSDvI2zUy18jmEhKCtASIa_zpHSQIBZyi saWvBmxa7AS_u8PKI2vV6dNA0hz2mH2_3QEXOCcbyzTMzxnk90YzqxgQfuWbUDwLfmjuIaqLYb.T T1LmegNPXzBf0X0TubQ0Xn_0OzzOduzSB8tlg0NU5sT5WPBWuxdJBYu8oGn03nFSNWp.alEcA6jc 44bhxZh8Kh7wvn.529TidX2vlIUdBinyAW3zOvZeOd4dZJDOI0Gpdi.t_O.didYsI_oe9krLL__T PRld8IYLRyBWrT86iNjWEjJLG1N01Xq6MnzOtYte7QQGn8Toqc1fzJFEi4vca2SF9ES6aaAfAO5_ Re1Uihac3I5ow4RE7vGO3vsWnhbEq5wWo7aC6eO9s_mcmKxtboBmM_9BQSMBjibDxG4Xcfqux2bR 3EReT6U7HRQTWbPpE3YJiJ8gBHQ8kV.TwEQ8bVcixfA0T7qxBQN2qZ83BPdDcde9OYhak6R60osT dNViZeICIulCUrwXJQmTx.2oxegAaPibq8pUJznE7IfeMQqKuD0QACdysGxnsi7UoN7n.Aw1Gw0N JhsElAGpurYLtSDe8gAAm9ih2p11UJcOQsX0auPvq5xUPioPeO1WLe0RfknMbI7Z5ShEe14p6hQt u1AM1eQ1dyO4zjLHAWAAaIlZncO6pjiGqomXQp2DyWKn_AOV6MCatLFiZL4BjhiO8e_26JZ9orEF UVhhTnPM5A1xq6FoS.Q1JhXW1WeLxhMK9RJVj49f2lGClnTRexBdlNTUCd9wtIzYI0J9NsKBbpIz 1lR4YUDp_vqDHCjTS3gxllGlJa1VRlvriCaqtff7q3If8XYMNHsL_8fm1ciy274JTGqtJW4oKyHP 6RgX1s_8Ssi_EpP4bfY_3gVY4kVMVrZ8LvPnVR901PAk94BLjrq6bksd4isX_XEJAA0crFaRrYCT qhu7wplM3VkXeKSSUU8inGnZdODquMUJNxzolILXo8gezMPbeRDsSxuYqbsPUrFWXLgMdRgBKM1Z eC7FVndIeZ8EyPTzFa.61hQyBE5eNVcGcO37nC3ynJVKuhwq2TjDWw4cyC3lFia8bcEUAjdT6Xhd O3n.SLw.T3UN87sBURqtGWK8ZbbMUZZ8_gaNHM6NtMe9gdtKvLn3GQ1tzL_v1JA1RQkz7U0Vv0X7 3VrBDE83eo30ACvL4TZEOEEjkpoL30IJci566qxqKO3iOz5MjV3tuW2z7tVfLiMbnsUb15fcE_Jl .OItq1nQHCJIinG.xdplg1nyKRb512ijD0WFmkbT3zlGP7m51WlDO1NyEB7SQefg30oTH.jJCWQX MHBUwiLRCjPoixSP.TdAvHQ6XumDSG3wdMUeRdVB8MHPOZlsJnVVpr_kjTLxcZv3d6VdQEFbkPx. LAPHHnKMYHowU4681K9iRVl7aIyzVlUwevWhByPeJi5NG1n89QTwVB21psaUY6m6mt1d75ARJGo_ SRQdEuJjG Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Oct 2020 16:01:47 +0000 Received: by smtp401.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 951cb00b4ca334412a3e8773b5eee046; Wed, 14 Oct 2020 16:01:40 +0000 (UTC) Date: Thu, 15 Oct 2020 00:01:30 +0800 From: Gao Xiang To: Matthew Wilcox Cc: Chris Mason , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Guoqing Jiang , Miaohe Lin , David Howells Subject: Re: PagePrivate handling Message-ID: <20201014160116.GA7037@hsiangkao-HP-ZHAN-66-Pro-G1> References: <20201014134909.GL20115@casper.infradead.org> <20201014153836.GM20115@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8\"" Content-Disposition: inline In-Reply-To: <20201014153836.GM20115@casper.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailer: WebService/1.1.16845 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/15) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.006560, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Oct 14, 2020 at 04:38:36PM +0100, Matthew Wilcox wrote: > On Wed, Oct 14, 2020 at 10:50:51AM -0400, Chris Mason wrote: > > On 14 Oct 2020, at 9:49, Matthew Wilcox wrote: ... > > >=20 > > > Also ... do we really need to increment the page refcount if we hav= e > > > PagePrivate set? I'm not awfully familiar with the buffercache -- = is > > > it possible we end up in a situation where a buffer, perhaps under = I/O, > > > has the last reference to a struct page? It seems like that refere= nce > > > is > > > always put from drop_buffers() which is called from > > > try_to_free_buffers() > > > which is always called by someone who has a reference to a struct p= age > > > that they got from the pagecache. So what is this reference count = for? > >=20 > > I=C3=A2=E2=82=AC=E2=84=A2m not sure what we gain by avoiding the refc= ount bump? Many filesystems > > use the pattern of: =C3=A2=E2=82=AC=C5=93put something in page->priva= te, free that thing in > > releasepage.=C3=A2=E2=82=AC Without the refcount bump it feels like = we=C3=A2=E2=82=AC=E2=84=A2d have more magic > > to avoid freeing the page without leaking things in page->private. I= think > > the extra ref lets the FS crowd keep our noses out of the MM more oft= en, so > > it seems like a net positive to me. >=20 > The question is whether the "thing" in page->private can ever have the > last reference on a struct page. Gao says erofs can be in that situati= on, > so never mind this change. Add some words, just my thought... we have a management structure which c= ould store PagePrivate page cache pages, !PagePrivate page cache pages, and no= n-page cache pages which are directly from buddy system. and I knew the extra refcount rule for PagePrivate from the beginning (si= nce the rule is quite stable for many many years (I remembered from 200x intr= oduced by akpm?) so I designed the whole workflow to handle these different type= s of pages in the management structure based on this rule and to make reclaim = & migrate work for all page cache pages properly.). I think many modules th= ink the rule is stable as well ... anyway, I think there's always be another = way to handle the same thing if the refcount rule is changed, yet I need to revisit all current logic and do proper changes. And I think many modules (including out-of-tree modules) could be impacted as well... anyway... Thanks, Gao Xiang >=20