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 C0978C3DA5D for ; Wed, 17 Jul 2024 22:38:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24D696B00B5; Wed, 17 Jul 2024 18:38:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FE266B00B6; Wed, 17 Jul 2024 18:38:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 076F36B00B7; Wed, 17 Jul 2024 18:38:42 -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 DDDEF6B00B5 for ; Wed, 17 Jul 2024 18:38:42 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 670CC140BBA for ; Wed, 17 Jul 2024 22:38:42 +0000 (UTC) X-FDA: 82350710484.29.9A94F4C Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by imf20.hostedemail.com (Postfix) with ESMTP id 2947B1C0030 for ; Wed, 17 Jul 2024 22:38:39 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=c7wzssSI; spf=pass (imf20.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.22 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com; dmarc=pass (policy=quarantine) header.from=gmx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721255900; 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=xPrZzVvNcdHdHnuGibZ5iF0WjkNUK2IMySL628CV+78=; b=ZMgbYO+tT91fxHRvaxqHVXi6Eb6Dw97E9v9c6efTwzEwWlcEdUOPSv/FvUUWJZ5Mt2CAJQ 5DrN/oQz0vCfvJQQgTCH16pz+DXLD8MaaWaPbwNWEHzo91aXj3i/U5EVqqf65hysVloFPd eBKYHkVRUA8TnSli4VP1uWA6rBU9fZE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=c7wzssSI; spf=pass (imf20.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.17.22 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com; dmarc=pass (policy=quarantine) header.from=gmx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721255900; a=rsa-sha256; cv=none; b=W8F+4ZFLujGIukeTavvE1t1NX9Eiw2Ti59rXfo802hyjFFj8VwGQSSw3uTHt0spX63mg3B 4w9wNVlAR17AwQ0XRyyRMviJLT0zDrXZGEkN86/ACq7CXjr6kiiPzOZXjX0ts7Z2XBSBVz j8LVTaqMIHeRoZzRDyvHmuGcRLLLCnA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.com; s=s31663417; t=1721255917; x=1721860717; i=quwenruo.btrfs@gmx.com; bh=xPrZzVvNcdHdHnuGibZ5iF0WjkNUK2IMySL628CV+78=; 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=c7wzssSI1DS/wbdDhHS0PRgf3EPYQ6ZKC4jA2UM5kZFkbfszqBwYsbd8Ua+x8Kee ppmQnHQyE0v0m5ke/agYCW02UIIPIjsVSEUpPPjaYIvXqmQG6oPQYd/GXqXfAlHbU S/TLKwYEDYXbJy1zNfz8TuG96uhy1PhDH1PZxX5Hss5cyBUigo/YXw+AEc38KW28U 3MHJnAQ9nG2lpa+eX28KmlHUK4ot/OspjOEXm99VNNeqx53ZMH8pu1qsmcUlKVCjK bU+/7zeOGKNBIIr0KCu5sVZz+npZWhghA5Wtb0sPsKAQLKqJJE4/UjFM4b8x9pvDj DRIJf09roiEcPnd1Yw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [172.16.0.191] ([159.196.52.54]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MmULx-1s4GC52DhJ-00eQUd; Thu, 18 Jul 2024 00:38:37 +0200 Message-ID: <9c0d7ce7-b17d-4d41-b98a-c50fd0c2c562@gmx.com> Date: Thu, 18 Jul 2024 08:08:29 +0930 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] mm: skip memcg for certain address space To: Michal Hocko , "Vlastimil Babka (SUSE)" Cc: Qu Wenruo , linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Cgroups References: <8faa191c-a216-4da0-a92c-2456521dcf08@kernel.org> 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:+4QnQQP9BMboYyQs/2n6exd6SgObnrelKctk2B0hezSTPpkkRXq X5NZRZyQp3GTQdm+7/xScAWghDvDh2iaU4LspcflVEX0OU6Kk26U/ef1E6cFfvsZ+x0UQGk 7n057tPnx3upVMzo+3NQIijTwA2XZjJNNZAU99QNgzfIKatR8O6aEwSkiRijIlDyR4HXvOj NZNPWmulF3N/aGIkgqDEw== UI-OutboundReport: notjunk:1;M01:P0:E+pFkZCKcYg=;Ff5j60pZla+04l+O8uUjORN1zWX txyIEsMY1aKh7ptBLNi2luTljwmerzSR5nJuwYP/F7g/SXwC1Cys7offurMow9cThssabKNfV ieX4ILgEncc9BVSOMaO2F9hfn/Vf8i7i6KJNKCfr6onp6018D48+aHPx3UCdZcqdHhTxKHQ9G Wt4urgTFn6jlG0zVM7liRaxOui9lXZLpIeQINvygxcM4GPb0JNI+LqwEQ0nMrpG75aF2ccGm1 hs1nXN8VwF097DY21oEHh/YWW2A1sdMVRQJR67vTtb6Kcz+ta1ynrIGcFYNQmH43hawdZDXnM RASirepRD65tUJkvSyQd4R3UUdw37XMUg0W8J24i+5zd2Yq3MVaPV3Q/WP4Zi4776di5PcmV1 ctLl5d6KU7TBY83aUjHh+abDAxnzPqwLRluk+NXVZLXXpMjYzrYHW8QhCMG3DoKiRaO/M4Jus 9jQKnwiy4eXgEdXweT26tpwlr3skDZMAK9Tx1lBLPdWmSr5/ptS2PJv2Qt7ZHvEOJjVZHedoh VjRupimWNMKtGyyr+KJ6112qep+vsW36f2h+6AsNmypcQRJhrc9IYstTceNyRY6wVZvH/Hb9a coHqiBya9b5ybn2W5YQ+8dvaOX7D875+YGYvk1O2vLffnIhZcfn0/6INr9icE3AVFt1EKJbxe rQc3MM1faGUqY46IHxIAJ/V7I0pDHz6Qdg7i0qayNmKfywtr/GufnKBxYSZF7b0kAmG+c00Ea doivp7GomWRR/sjUZQhO7CEQxMGwHigJOPJlfEwoQqukVcfOexujynxDsfPe1MMAsaCWmntcP D96vCUX/xUMwE6h0fzk5m5WA== X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 2947B1C0030 X-Stat-Signature: j3797d1qakw6w5k7jwe8rzki5wpxxhmx X-HE-Tag: 1721255919-11482 X-HE-Meta: U2FsdGVkX19rjHAGQkFBtc2Ko3/D6qQtnBcxJSCnFrA41ZI+diiGfHuWdHsJ5Q4HjRCK+e0OKN1JNK7JtOaMjRm9917e6JfTW1A0BqPElfvictcQQfCYkwSwg69KIYoRKDogl6udcxAz8+AQ/al79sNihwla/og9vg+yYBDjDoxJimkGhQxMn0PHZdeCMOzeSn4pu8EOZyzLYgQL2aOHBbyZjSjI4OygdApkEM90OmgKSOVMPOE/FyvIIhf7WbXnz9Bsh0ujcsEzD4l1Q1OAyJBFWYnK+bOeDz2AsfQEL3vqPoLFy5MoLIQ3tywr2R4ZVWWfjj4v3kKud47Jeem7Xud8saCJ/thpYckirtpXYPj+OWOkZw9BS/or7OdaUyTfqTehA2hwb+KyfxgKZod3BYGlR/hF8UoGTqzp2VtZTyYOfPoCRwYhfIu5P1UbbgUS6pbAF7ziPoLcJGnVpr6HalJu5N3tjeB+fkAvpOQjnEZlZt/vxyc1vupcDA2IDsx85wPWGuu2yqWN3Fwfdp5S8yVSz08Fo76psrSymwz1umL/dSyYsBi3Ak9pCj9h7hkNn/NdXTOKvvFRmni0tZR4gyKcDE3Aewiyn+YWmqSw6sLnKtoOltHp3+VnHKjb+JHNRbNPVgW004PMdyTnrowgR2bKSx1wBpn+CCDB4LJVkHINpzffSowZBZ0TdITN6urROjIiAaiwZQRFbJdzJPQvFzHmS0QLe8F2SSHMcImtiTE8vfAQtLCxCvkg0k2V0T2DvDfjw7fYd9isMxxiFkhLuTm09KrkcPP6aYxIFc+qqAZ5s9GGUSq3Pk0bm94/OG2JDnkTgv0de08T9BvddBuGHc25pS08YxvZ3ZrdnPNOckD7XnHDsgXIpITanYFEEfTYaIZzDIMLxWAYtqHJgWvd0qZFu48+CmT16t9B9Z9/nvHM15TKiE89u+2uTWgJIx1EmQOcTgvV+taJkWXX/5u sInXTbRC GXJAYvJtYtdvTiTH+vKj48Sc95r1r7CUEx5FuOOUOTcU8CYjydKu9ubcNA8I+juas7FkTAOphWcqzvJEdnupuqGUlhzCYZVRZcpzbeFQ+70MiHBfxjW/97KMFX9K5LglMOxsxTPB7ENwRoog8kjOZUEoEDYyeBuH/pAI9DYmvpQGlTaKRqtuCrZHtb1k4kZ2hvZVFRNR9+U5rHtfi6TgOspwnJ3/DZqfA5RdnnynuN9CXRwkHuOsneSYnQeU6A3o/CG4R2qSezf/YQeHjZbwHjKo0NYVNBdSAvEJtsUxs+DU+u8E= 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/7/18 01:44, Michal Hocko =E5=86=99=E9=81=93: > On Wed 17-07-24 17:55:23, Vlastimil Babka (SUSE) wrote: >> 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 th= e >> 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 fir= st. > > Correct. memcg oom code will invoke the memcg OOM killer for NOFS > requests. See out_of_memory > > /* > * The OOM killer does not compensate for IO-less reclaim. > * But mem_cgroup_oom() has to invoke the OOM killer even > * if it is a GFP_NOFS allocation. > */ > if (!(oc->gfp_mask & __GFP_FS) && !is_memcg_oom(oc)) > return true; > > That means that there will be a victim killed, charges reclaimed and > forward progress made. If there is no victim then the charging path will > bail out and overcharge. > > Also the reclaim should have cond_rescheds in the reclaim path. If that > is not sufficient it should be fixed rather than workaround. Another question is, I only see this hang with larger folio (order 2 vs the old order 0) when adding to the same address space. Does the folio order has anything related to the problem or just a higher order makes it more possible? And finally, even without the hang problem, does it make any sense to skip all the possible memcg charge completely, either to reduce latency or just to reduce GFP_NOFAIL usage, for those user inaccessible inodes? Thanks, Qu