From patchwork Fri Jul 19 10:28:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 13737163 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 B4012C3DA59 for ; Fri, 19 Jul 2024 10:29:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 316306B0083; Fri, 19 Jul 2024 06:29:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C68F6B0088; Fri, 19 Jul 2024 06:29:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18E8E6B0089; Fri, 19 Jul 2024 06:29:08 -0400 (EDT) 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 EE3EE6B0083 for ; Fri, 19 Jul 2024 06:29:07 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 765A6120577 for ; Fri, 19 Jul 2024 10:29:07 +0000 (UTC) X-FDA: 82356129534.07.73671AD Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf13.hostedemail.com (Postfix) with ESMTP id 3DD5820016 for ; Fri, 19 Jul 2024 10:29:05 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=kUjE8tRy; dkim=pass header.d=suse.com header.s=susede1 header.b=N0cCXhpt; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of wqu@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=wqu@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721384914; a=rsa-sha256; cv=none; b=hPt38BizoUpM/SokaQ8i9nQcxfK9T1/03JmbSlTkPq28WLRNvFzComw4p1Z9hD2jnPc1Da 8d9cDKpVr9FA7bonFEceChr+/uaX8SSpdLDztCl1FpYBUfNGhra5Gqhxxe74xBmtxxLaT5 HHlodl2eFgYwmtVJNkkhPSGET8uQjkQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=kUjE8tRy; dkim=pass header.d=suse.com header.s=susede1 header.b=N0cCXhpt; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of wqu@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=wqu@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721384914; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=Qtm81WYplQY/AAVE+NrlpaQY5A14Fa+JQGPgeZwLP7s=; b=tfdASjTuttIVDgpgotRA7j7k0AZtwFqDETLDj9OyyEx0rVsKqJl5kF8Hbz9uys9St8wna7 UJrYxv8b9r+6lQKae2D5ww9YilNRy6q8PfHEOF7D4fQ+yJTpig9j56QQmzFoFRu1QXwW7h LLK65ze2YgFG2xiCTY6FL4xa1XF9eFk= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 89B0A1F79C; Fri, 19 Jul 2024 10:29:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1721384943; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Qtm81WYplQY/AAVE+NrlpaQY5A14Fa+JQGPgeZwLP7s=; b=kUjE8tRyOmOdPAyWL4CBjzaS/NVNEkkTK2cCUGMd6FGRlGfOpSkX1k8dnRLhE22/kkYMs1 veShvo1sOPZmC8ScySjC4IuSl1IUW7Gv69bFaiEqyq5b0xzPF4pCatlwV9nNcaLshURqBU ne9YJUD8iJ4ra/eySL2bzpZYZZ70DOk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1721384942; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Qtm81WYplQY/AAVE+NrlpaQY5A14Fa+JQGPgeZwLP7s=; b=N0cCXhpt2SCpaK7AW96VukSBqDoY0iuRsjUIvxuJOQ/BY0eQPPPTCaAzPmpSOiQhP1eMDJ X1uuZctIRy+BzkCeucZW9mysk6u0Mt/JKzh3bZOPA0N5z3WChhAJrEXM1DttYhmIefKRM9 fX3TAGftsZ66xSBObx8JP3tHWI7RNqI= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id ADF06132CB; Fri, 19 Jul 2024 10:28:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id iTNQGes/mmb5WAAAD6G6ig (envelope-from ); Fri, 19 Jul 2024 10:28:59 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Cc: hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v7 0/3] btrfs: try to allocate larger folios for metadata Date: Fri, 19 Jul 2024 19:58:38 +0930 Message-ID: X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 X-Rspamd-Action: no action X-Spamd-Bar: / X-Rspamd-Queue-Id: 3DD5820016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3aygbuct5wowgs53cqmbtfjp915wcxb3 X-HE-Tag: 1721384945-374647 X-HE-Meta: U2FsdGVkX18U9oVy9osCNiTy3yahGOa5fkrgY5rzsr7pHUUW4kabEZtbZW2QxC1tyQhLdCwVGzg8A7kyWaz7DUs1FHzIr1cfDhdj0QPfDo0nB5UWS+N2QuipTdp1+2CeggYEvneSkz5EAgFbtAy91jmoNCMxH/5KqupvwSCo3QoKHikIN/SCGtI7dOCOE18yIppN0fueiXxQNum8nwkRVQJODsgqPGHsZzPGNRT/DnpnOdjUo+8PaFH0moUt5vjwBPruLRlBpogQheXGmpSrdRwMWWDbTaRcTj32a7YqA2iLynovf3dglMECZjf0nCqucEt9a2EHTY9hNikx4KwLSlHpSgqHdr7K5wPrn2y0J+T1nYqsMMmEF4QrG04PTcSJ6pnI1Yfzsh/z5nn11cp+PZjNvcSXRSxjTIy7bpvyI0Wwknt+YkbB2YEY/b8yGtHlMmLRiN60UDHKGnKoKBg/WU2schZiRy/NlLj6F6hbRlE4HW9U3KaqjK6hm4masNjW1oVZhEB8nF1Lf9aPDgTb1rqnADt9hwpZlxvsZjqB0uiaH3Hl/k02/AV6SHJ4/ceS5AN5cBLMPMcxw3mBwhsaxdG1pFhd862gm6a9ASWeHK02fxrfsjRxXhJJWFFx0Oq30fBRy9vdiDtliNGKmYDm0rRdlZpF69UU7kba2W9SUGPa1YvQAhuMbw4sRH7cFjPaKYUH9TjkRq5B4ByaL5MGNxrWdzqj5dEY24+BX3kmMFiuy2nCpleKBuppIHFQ0+yyUfxy5EbRE815UlX0mElOKXWHxUI6k0UXy4Gh1CWUrg0lpSxfhxKVUfcygue4wUq1HeBaAQMobn7UMmx6Hc+lCSNnTQksOBL5oftGj/r4BFJQM+YIuUu98f6EuCUfy5ArSzUph/rMqYfApqJtqjhr87Nx1sYCar2pPA1XAmrUhorOzEyBnNAkpDcn8/19StMM1vt661N8gw9oZXePUIT dkbGusj2 pDZfqDnTcUMp9QMduBMdytJYlONr5O+ugmI/JsoQ4N9XIghx4IkhMfvZoOCIFOfogavP3SGx0jDjrqhqpY61pXK8H3jYr2L2ygx/vqIlxbfZz99fTq73u0pEyCHNlVmxB065wejVzWJ3uenGFxWbwXCH37Uedd5DRbigW7By/EVMyCtSE/4fPIxBYWLkBKZqbh2BwL0OWSBBX1y8= 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: [CHANGELOG] v7: - Fix an accidentially removed line caused by previous modification attempt Previously I was moving that line to the common branch to unconditionally define root_mem_cgroup pointer. But that's later discarded and changed to use macro definition, but forgot to add back the original line. v6: - Add a new root_mem_cgroup definition for CONFIG_MEMCG=n cases So that users of root_mem_cgroup no longer needs to check CONFIG_MEMCG. This is to fix the compile error for CONFIG_MEMCG=n cases. - Slight rewording of the 2nd patch v5: - Use root memcgroup to attach folios to btree inode filemap - Only try higher order folio once without NOFAIL nor extra retry v4: - Hide the feature behind CONFIG_BTRFS_DEBUG So that end users won't be affected (aka, still per-page based allocation) meanwhile we can do more testing on this new behavior. v3: - Rebased to the latest for-next branch - Use PAGE_ALLOC_COSTLY_ORDER to determine whether to use __GFP_NOFAIL - Add a dependency MM patch "mm/page_alloc: unify the warning on NOFAIL and high order allocation" This allows us to use NOFAIL up to 32K nodesize, and makes sure for default 16K nodesize, all metadata would go 16K folios v2: - Rebased to handle the change in "btrfs: cache folio size and shift in extent_buffer" This is the latest update on the attempt to utilize larger folios for btrfs metadata. The previous version exposed a reproducibe hang at btrfs/187, where we hang at filemap_add_folio() around its memcgroup charge code. Even without the problem, I still believe for btree inode we do not really need all the memcgroup charge, nor using __GFP_NOFAIL to work around the possible memcgroup limits. So in this update, suggested by the memcgroup people from SUSE, there is a new patch to make btree inode filemap folio attaching to use the root memcgroup, so that we won't be limited by the memcgroup. Then for the patch enabling the larger folio, I reverted back to the old behavior that we only try larger folio once without extra retry, just to be extra safe. Qu Wenruo (3): memcontrol: define root_mem_cgroup for CONFIG_MEMCG=n cases btrfs: always uses root memcgroup for filemap_add_folio() btrfs: prefer to allocate larger folio for metadata fs/btrfs/extent_io.c | 112 ++++++++++++++++++++++++++----------- include/linux/memcontrol.h | 6 ++ 2 files changed, 84 insertions(+), 34 deletions(-)