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 E5B6EC3DA42 for ; Wed, 17 Jul 2024 15:55:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DC086B0098; Wed, 17 Jul 2024 11:55:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58B586B0099; Wed, 17 Jul 2024 11:55:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47A436B009A; Wed, 17 Jul 2024 11:55:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2B3476B0098 for ; Wed, 17 Jul 2024 11:55:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C116040BB1 for ; Wed, 17 Jul 2024 15:55:36 +0000 (UTC) X-FDA: 82349694672.16.CA77164 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 083841C0023 for ; Wed, 17 Jul 2024 15:55:34 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gqHERqXN; spf=pass (imf18.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721231704; 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=yNnc7GqzQmVCrDj6bRP52jTjdN86nFu4JiUHU1qeM+E=; b=wVQg87FZt9RSNHhm3CVpwGZJDMGaN1jB/BKwrypGZbXhHHCrN6eCJ+W50aIe0AhR84uwM5 W3Q9mVRVak5E77cOj2fMI5cjt/TFci3DPsmFh7Yd1gRM0l6T9ue6lnsM+tAAKy2wdEnPDV 4f5mqrTGlgW7o7JJZ1ZG4KDcjsllNvo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=gqHERqXN; spf=pass (imf18.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721231704; a=rsa-sha256; cv=none; b=LUTaizxmoOwMeoPihzcDBv464/MvqdFq9m/lXiG3IIqFdoBPQXBWllvFJ8LvgUcDcWIINn dgj5864rrGjrC0CZrfh2W6vsmwEe0XtzTO//peRMdgy0nPwjBCWW2/aAwOJV6KiPya68Yq J3fU6XP6DlutouXkFhA/VQM6UhU65MY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 052F96140D; Wed, 17 Jul 2024 15:55:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CDC2C2BD10; Wed, 17 Jul 2024 15:55:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1721231733; bh=KGYzxcxkej2/t7nvEAu723VbQGmVlxb+q+JmXx84L0U=; h=Date:Subject:To:References:From:Cc:In-Reply-To:From; b=gqHERqXNb5QWjzvIjmYjQKpI72SZinvWN19JsgmBepXKXLISAv4luEhMgLWW5LOzu gDvg90TjWLgvNeK6sHUB10Em4XlX0H/qJdEu2LGbxak1kO4o1WT53mjTcRXm2s8nOJ fxhOeGINjz6CXFkqcUECzFdUPQvsnSi2xBWyAYc9crIWAX28LmH0hNnLMb62nwG2Nc 6ZsXLFrSbd8gBG17weZZ4s7aKWPZdRLiUmrGuorku5bBC2lRxIZfeAFsfsqL/hFLEb Sz9Hfd+mqx3Z7WYnkjjdLwRcniTTIeKJ+5uRF6qfaYmauJBTZj4RhWStuWxxyoY7ok apj2pWy/+le5A== Message-ID: <8faa191c-a216-4da0-a92c-2456521dcf08@kernel.org> Date: Wed, 17 Jul 2024 17:55:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] mm: skip memcg for certain address space Content-Language: en-US To: Qu Wenruo , linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org References: From: "Vlastimil Babka (SUSE)" Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Cgroups In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: c45oxncchakubrrrncf5nbnidr8yb9p5 X-Rspam-User: X-Rspamd-Queue-Id: 083841C0023 X-Rspamd-Server: rspam02 X-HE-Tag: 1721231734-199130 X-HE-Meta: U2FsdGVkX1+HD4xiDWKwnvf9hh+EV8cPVUUKOgKvNPicjHKOMVycw0Pu8Mvge5cd//O5pNEe9c/0wI7erfbvJoGjmnCuLILdWRy9lOdUUpFSukBMO5MsfHh3xMuubkBYMV2qC7YFJR1N6T7loC/nvQ/lX/NLeYaoleevpgm64lSErrnJfd4nkNtHyiXAqKH56/D8rFX0rDSXkVFOgxDFny7xSM3A8YM3sq9zCKVrGl+iTBFElo9SniC1heFZd9015PH/gHJWleHn6d3EuAUgCrL1G2PZHjTEhDBXSFQX5/WImf1zjMnHx/wCfJHQyBTsT6hxRwQPZ/xdd6EtpQ6fOyhaBbnEBRVWBVhVbtrtSkG9iwX8sYot5a5EN13W3Re/u3APRULQlWo2AgqGAQAP8zshvx83zRImOO3cvxLu3BSu/fnP9MyeXOfzXpuEm7lXEOlTUqhRiRy9TlEcsJY8i4071RVvuHSRY6AY4xoUX2FcDYnIl77apv4nTHmxAUpnNrmHDVqDXNHEse4LlwsUIdlhrf+ePtoeXDVx2WfGGpyrckcn0DIavfQg4l8ya25f+/vykIvzKQhGVbLUEPU/ZV9tb1CzHEFOBcf4KbqrNc4VzKHTkDP5/pY8r/TZdoKwVZ9ph7xCrWMmmDfP7ZjSRagzjhu/+uiKdkTf2N9tV51JwdZME88aS/H3aKjGJP8L7+A9uWPu45a9gXFu9FXOvFyfBiJj9IZfODECjkA+nQVN5vYuNXJM6mvhvNblfypgy6HgKpVYZgWfKi4F3wdQ8kRyB0f9sWS1p+ew8wlbP+Cz60Ch5UD3fe5ImD7LJvWFbAc+sbksWe67ePaSJ8eQFyhPLtYaxOiE1+Jv33ZyfJuzGPEObLi78glku56XtXLIDEtGTqFP/lQ/ol/ssmb4B698MkicKMgFEM3Jjt/mmIttdptoePOVOeEtOySXYE5s6eMWGWW4CZFCiGZSUYE qdf0FzJq hlv9eq4+Jr2EoZZ/JR9h+y09u0MeT6FV9HsaSMDMd7Em2HSGtT4gBoxSKPI/sTlmZJQ8seK5PsM8MkEzrj6b1fVW8eWXQZfvQw+BTGUdFVltiKtnB9u0Xvve3+BtgWdcODaCVxJCgZwu1xkrZr2qIop9EtpWkglI2ic8iK8LS1Xc81FFSysJ3PEMpZfXfNwk9pgUONumrCZ+cg936x2AIr61Tn0rE0AkfZrfA 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: Hi, you should have Ccd people according to get_maintainers script to get a reply faster. Let me Cc the MEMCG section. On 7/10/24 3:07 AM, Qu Wenruo wrote: > Recently I'm hitting soft lockup if adding an order 2 folio to a > filemap using GFP_NOFS | __GFP_NOFAIL. The softlockup happens at memcg > charge code, and I guess that's exactly what __GFP_NOFAIL is expected to > do, wait indefinitely until the request can be met. Seems like a bug to me, as the charging of __GFP_NOFAIL in try_charge_memcg() should proceed to the force: part AFAICS and just go over the limit. I was suspecting mem_cgroup_oom() a bit earlier return true, causing the retry loop, due to GFP_NOFS. But it seems out_of_memory() should be specifically proceeding for GFP_NOFS if it's memcg oom. But I might be missing something else. Anyway we should know what exactly is going first. > On the other hand, if we do not use __GFP_NOFAIL, we can be limited by > memcg at a lot of critical location, and lead to unnecessary transaction > abort just due to memcg limit. > > However for that specific btrfs call site, there is really no need charge > the memcg, as that address space belongs to btree inode, which is not > accessible to any end user, and that btree inode is a shared pool for > all metadata of a btrfs. > > So this patchset introduces a new address space flag, AS_NO_MEMCG, so > that folios added to that address space will not trigger any memcg > charge. > > This would be the basis for future btrfs changes, like removing > __GFP_NOFAIL completely and larger metadata folios. > > Qu Wenruo (2): > mm: make lru_gen_eviction() to handle folios without memcg info > mm: allow certain address space to be not accounted by memcg > > fs/btrfs/disk-io.c | 1 + > include/linux/pagemap.h | 1 + > mm/filemap.c | 12 +++++++++--- > mm/workingset.c | 2 +- > 4 files changed, 12 insertions(+), 4 deletions(-) >