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 93828CE7D00 for ; Tue, 1 Oct 2024 09:40:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF6C7280065; Tue, 1 Oct 2024 05:40:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA633280036; Tue, 1 Oct 2024 05:40:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D20D2280065; Tue, 1 Oct 2024 05:40:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B0BDF280036 for ; Tue, 1 Oct 2024 05:40:21 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 20F0E40966 for ; Tue, 1 Oct 2024 09:40:21 +0000 (UTC) X-FDA: 82624537842.12.4126C05 Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by imf28.hostedemail.com (Postfix) with ESMTP id B2C06C000D for ; Tue, 1 Oct 2024 09:40:18 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=ZAIcb04j; dmarc=pass (policy=quarantine) header.from=gmx.com; spf=pass (imf28.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.20 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727775525; a=rsa-sha256; cv=none; b=YCjGupvcT9KHk8emjAI451cMYVOj0I1WN2KTjsFVrlGaQiWfOMbHeJs6O2qgeX0IUkHIiK oPmB7W2yPZ8sgZafO8y3wA4cGBlI5mPwv68+u4zorTEzVWklJOhG2DC9IhiRHgSRtxVL3z iZzpYztL/+h7QKhlRl4NTiJP/fG1F44= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=ZAIcb04j; dmarc=pass (policy=quarantine) header.from=gmx.com; spf=pass (imf28.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.20 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727775525; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IfGAGOIYYuqBWkCtoXPPwiYwgrjz3A5ckBd5Hy1y424=; b=6kwidi2jD0ra3bLLV9lNxKU/vitrH4UzTHnqPTRiQUtWwgIXSn/3Zrm6UQeG7bc+9aAcN8 zPXRN2mY7eejLlQO8GqmfKTwvd1+jgKd9AuO3Q40ZQKoZJbZgw26zHF4pH6+vT2SaxA+FL aGV9S5x+V6FgsiDtzcX4D9q1le7izyc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.com; s=s31663417; t=1727775615; x=1728380415; i=quwenruo.btrfs@gmx.com; bh=IfGAGOIYYuqBWkCtoXPPwiYwgrjz3A5ckBd5Hy1y424=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=ZAIcb04jWb+rVwj+5EktR9OwhNmL4WOI6rLPdkV3+nHoTzxDVuxIzhKM8xbJQNI0 ysnVrfp3TP0/LbuLx+ygOa9lvA0GRG1cp5bFMslpzA0dQd60dBrLtph2pmsYSc+8C 2of7u7/Ob1ayB34xjeh8e69qtUnSYLYdKnK4drzDNUthkuT0+NJY/tExvnIIi3DUL EHXi7tzPHRVkJl+CAbM77gIFlPH9I79xWdiSiQuoE1WSXyzsHvhzEnSlFlyHFd2y8 d1cFtQTCSixkNgxeaIA9ad3UfqFDDSRyMALc+mg0wNzK37TZLk3+jQJD2TYB3xGad Y9Eu12/BBSEJR3bvlA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [172.16.0.191] ([159.196.52.54]) by mail.gmx.net (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N6bjy-1rpmPQ3N30-012G4f; Tue, 01 Oct 2024 11:40:15 +0200 Message-ID: <5d3f4dca-f7f3-4228-8645-ad92c7a1e5ac@gmx.com> Date: Tue, 1 Oct 2024 19:10:07 +0930 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] btrfs: root memcgroup for metadata filemap_add_folio() To: Christoph Hellwig , Qu Wenruo Cc: linux-btrfs@vger.kernel.org, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , "Vlastimil Babka (SUSE)" References: Content-Language: en-US From: Qu Wenruo Autocrypt: addr=quwenruo.btrfs@gmx.com; keydata= xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB AAHNIlF1IFdlbnJ1byA8cXV3ZW5ydW8uYnRyZnNAZ214LmNvbT7CwJQEEwEIAD4CGwMFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AWIQQt33LlpaVbqJ2qQuHCPZHzoSX+qAUCY00iVQUJDToH pgAKCRDCPZHzoSX+qNKACACkjDLzCvcFuDlgqCiS4ajHAo6twGra3uGgY2klo3S4JespWifr BLPPak74oOShqNZ8yWzB1Bkz1u93Ifx3c3H0r2vLWrImoP5eQdymVqMWmDAq+sV1Koyt8gXQ XPD2jQCrfR9nUuV1F3Z4Lgo+6I5LjuXBVEayFdz/VYK63+YLEAlSowCF72Lkz06TmaI0XMyj jgRNGM2MRgfxbprCcsgUypaDfmhY2nrhIzPUICURfp9t/65+/PLlV4nYs+DtSwPyNjkPX72+ LdyIdY+BqS8cZbPG5spCyJIlZonADojLDYQq4QnufARU51zyVjzTXMg5gAttDZwTH+8LbNI4 mm2YzsBNBFnVga8BCACqU+th4Esy/c8BnvliFAjAfpzhI1wH76FD1MJPmAhA3DnX5JDORcga CbPEwhLj1xlwTgpeT+QfDmGJ5B5BlrrQFZVE1fChEjiJvyiSAO4yQPkrPVYTI7Xj34FnscPj /IrRUUka68MlHxPtFnAHr25VIuOS41lmYKYNwPNLRz9Ik6DmeTG3WJO2BQRNvXA0pXrJH1fN GSsRb+pKEKHKtL1803x71zQxCwLh+zLP1iXHVM5j8gX9zqupigQR/Cel2XPS44zWcDW8r7B0 q1eW4Jrv0x19p4P923voqn+joIAostyNTUjCeSrUdKth9jcdlam9X2DziA/DHDFfS5eq4fEv ABEBAAHCwHwEGAEIACYCGwwWIQQt33LlpaVbqJ2qQuHCPZHzoSX+qAUCY00ibgUJDToHvwAK CRDCPZHzoSX+qK6vB/9yyZlsS+ijtsvwYDjGA2WhVhN07Xa5SBBvGCAycyGGzSMkOJcOtUUf tD+ADyrLbLuVSfRN1ke738UojphwkSFj4t9scG5A+U8GgOZtrlYOsY2+cG3R5vjoXUgXMP37 INfWh0KbJodf0G48xouesn08cbfUdlphSMXujCA8y5TcNyRuNv2q5Nizl8sKhUZzh4BascoK DChBuznBsucCTAGrwPgG4/ul6HnWE8DipMKvkV9ob1xJS2W4WJRPp6QdVrBWJ9cCdtpR6GbL iQi22uZXoSPv/0oUrGU+U5X4IvdnvT+8viPzszL5wXswJZfqfy8tmHM85yjObVdIG6AlnrrD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:czho8s/wZSHZPASACleHkjuRw7Wwzp5kzCYw05Fv9AKZI3BCtlD b+LqTUtHn+jTBCE6Q4mXyrXkiLX+NYg+xNM8d86zcabWqPNcX4NzELNKyKqQ0zKzTRTDfS4 X3JXGUGTexiwyFWVVgmVch29YrCzC1IA92EdON0kDGwqTdSvYlK0URnx2j9COB+empTFr7n 8zURrUqeBedUehXf0ZchA== UI-OutboundReport: notjunk:1;M01:P0:JUlayBcxy2Y=;XT9Ty0sIEGRbzmS80ksymiBMi7D jOwwhQY775AE0Ri1rCK9shB1sGEg0x0dYcfrOUFiL+yjByLdKk6hLFsoDox79lqSe+2i0M6Z6 aEWUI67EzPyh/yA39FbGUgN5Xwt8Uh0XhvDSB3u4a39mAWPdBC9Ka8m/AGd4MDJlL4lXpYFvV 7gVeCUKitmQ6TcvD9pHa8sQoEUA79kX8WDOgsrZAdg6fZj6hc/iDnG8mRdhA5ZAYhot4TcRh0 e+cPuzjSGHXu6vtztFEfacGaUOgIFQQ0guMjB4/RZSldE7Gz9Ug0wk/ZLlJSiJ6lst7So9PFd UhYc6CL8+D6vKXuY4vZZrwaQmeumBDfYiBjiMQan1FbtPq3sNvqCKoaxloXPDwCfeoVmD4bEO V011JZ6BRjcer2ekEPm/3ATdsrUhDHbIg5quf54Ziw/wj4w+jsuOlRt6ffmiCfirAjp4Hz8LC 4QkT0Z4mA2132+xYG2ZyPFSxmwbV2bTsZ8EmCNStHqlIi5HRTKU9g5JXLBYKaBOQz07yVHIxm CpxcfDwIEh/8KcYv/3rZ0IhyLbqM6RmquK8nArdmeWD7vKzynrx14TVeO6KTzqJWrnzRLI/q/ BfbSA6tIZB6kejCJlNJUU9gkHrzdivWUzM+MFeb8VIWV0EtZne+ILdZbn2XpAERfKpEdN+zzN kj0t5+3zOr4xqOHjG17zHSuyQduq5b5SwL5pPUaIS4N03V/EF7ewEpof8mxRGA/VgHlk1u2yd sLnbsfkyvi6DynrSAD+Vx8EGrnvqIyNoYJDqCL8D76mTemT+MJIRGXWXqfcsCPQTCc8BiB9h6 WwYTmAEtBWs4WTYcd2lmR7oA== X-Rspamd-Queue-Id: B2C06C000D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ahjsutqeu9pefwh3ydqidppfbjgrn7xi X-HE-Tag: 1727775618-136909 X-HE-Meta: U2FsdGVkX1/mnqqXN0PjiI6eTA+eF1m71USobLPXvcQJLZQcyLn5pizx9R25BrxXIloHp3e4ZMMRbuiJhUqAa+mRjpYhOGbImimvbD2owzaqRu139l/dQXV8QpCLVfb91BrBkGgQeL+aYIYlb/Duj6ZqUjUt+guL++MC2x4Sr8HlViuaWu1pmMptcWCA4zrLM/mB/iMfDESynSq/NrNqll2kmyVmodz3Af52mHAfgpeRFoVd/R0L4U8KJQDX23VOyhgljyJ+WlVmi0D9xTR0kwfe2VwMPEzOFyWy0UOOu9OcL/Efw2eOAXXcy2qLpGQhVRd2iFgktI5JnCkT5hVMRfiCTBuwXE1enLXcDtZbsPv9LEI53lTHSZcM+sAPEZhB33nHdBOP/oVvgx2wzNKw7EgUH+s4nZT0MdS59FG4v67UZWDLP7ucfFto9QUXdhIKyx5ZDqU/BIbe85nXPP+bZOzpDAZNMH5oFpC3REfeOseFWiywMdK9tYEFlrJpsqFFN0i65bDNWIqtmCafWje1uT2YHvqBCxQa0jQKu1ILLx1Ze7fT1T7L6CEXBrQTTlUCG2XKntOn1y9W78myjzIwIu8CEEiKn0+O1NIsMkx+db78yJFXlPREnqXc8JaBjwBoT6gWgqF6ZMNppkfYympfaqo8bGW5rFBpYF/1xr8nvwcLCJEncisCxCJqO92a7KMKipD/ajlkXdlpianK2HNkTPD6zYIO0D3x7f54PgVb87g+GpwTuV09URwxpbr5tz17xx0SG4umP6koXzVoXQ1u/t/ZtkAwgtPRDx63H8FKD/swJAgxPq23D/YUNgQ/gD+7wFn3VXyL5AGIFGG9kBMOzQcazrxz/eEjQIvjB2QVbQ0Cxtcf4HD4kNcck5KD5aTtXmQaFsjvzukRdN7QmQNTnhboadBYYXYYt2EcrNbPSNMOs9k8ombVCHNjTDQwwuDEijiiXC/SVrVFoZf7oGk tBGM8yxs 2N69SeE0SOAutB6QdIpmZnjJ6eM4nXn3ZoNTGCzSPBQU/n/tZnbAuenniecKKCqVmhPDyD5yULRnBfn/HPdUFG/extBfHkryZNx0ZG563QRyJrLjYXTpOsV23ZMy/U2BvKKoxsDv72GRGhBsOVZ24TwnCM/ASlHYzfoxsvX4snXqZkk+fZLIklYwEzsQzdLviwcy6+v4r3D0gl/RV9QAdJ7uArQYkdzjfksWP8xJvKg79pw0VprMJkHMIjcu7j5GwiEj8LNpXQJTXugsexDMjG0rvCw+8faOWud1TxrbDPZx+jaGPluCpFGVidO44IXINzLXVSjblKKbOmGJgTvx11uBKZTLUcKzScM5QRLv8H2y2IiF6C285ExTfsT7ap8ohVvgdhoX9nI4uRml/zNemzUcSMQ== 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: List-Subscribe: List-Unsubscribe: =E5=9C=A8 2024/10/1 18:49, Christoph Hellwig =E5=86=99=E9=81=93: > On Sat, Sep 28, 2024 at 02:15:56PM +0930, Qu Wenruo wrote: >> [BACKGROUND] >> The function filemap_add_folio() charges the memory cgroup, >> as we assume all page caches are accessible by user space progresses >> thus needs the cgroup accounting. >> >> However btrfs is a special case, it has a very large metadata thanks to >> its support of data csum (by default it's 4 bytes per 4K data, and can >> be as large as 32 bytes per 4K data). >> This means btrfs has to go page cache for its metadata pages, to take >> advantage of both cache and reclaim ability of filemap. > > FYI, in general reclaims for metadata work much better with a shrinker > than through the pagecache, because it can be object based and > prioritized. > >> [ENHANCEMENT] >> Instead of relying on __GFP_NOFAIL to avoid charge failure, use root >> memory cgroup to attach metadata pages. >> >> Although this needs to export the symbol mem_root_cgroup for >> CONFIG_MEMCG, or define mem_root_cgroup as NULL for !CONFIG_MEMCG. >> >> With root memory cgroup, we directly skip the charging part, and only >> rely on __GFP_NOFAIL for the real memory allocation part. > > This looks pretty ugly. What speaks against a version of > filemap_add_folio that doesn't charge the memcg? > Because there is so far only one caller has such requirement. Furthermore I believe the folio API doesn't prefer too many different functions doing similar things. E.g. the new folio interfaces only provides filemap_get_folio(), filemap_lock_folio(), and the more generic __filemap_get_folio(). Meanwhile there are tons of page based interfaces, find_get_page(), find_or_create_page(), find_lock_page() and flags version etc. Thus I think something like filemap_add_folio_no_memcg_charge() will be rejected. Finally, it's not feasible to go with a new GFP flag either. We already have __GFP_ACCOUNT for memcg charging purposes, but for filemap_add_folio() even if we do not pass __GFP_ACCOUNT, the memcg will still be charged. It will be even more ugly if we add a __GFP_NO_ACCOUNT, and such attempt is already rejected before IIRC. Thanks, Qu