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 E9567C3DA4A for ; Thu, 1 Aug 2024 22:58:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0EC3E6B007B; Thu, 1 Aug 2024 18:58:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09D116B0083; Thu, 1 Aug 2024 18:58:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA61A6B0085; Thu, 1 Aug 2024 18:58:08 -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 CD3256B007B for ; Thu, 1 Aug 2024 18:58:08 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7E055A7715 for ; Thu, 1 Aug 2024 22:58:08 +0000 (UTC) X-FDA: 82405191456.08.111CAEA Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf21.hostedemail.com (Postfix) with ESMTP id 724151C0012 for ; Thu, 1 Aug 2024 22:58:06 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="X/xYmjcz"; dkim=pass header.d=suse.com header.s=susede1 header.b="X/xYmjcz"; spf=pass (imf21.hostedemail.com: domain of mkoutny@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722553041; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LrfpBRx2OlghlnQUP396vQ52rxWepmoXbexqsA06Cq8=; b=Ap5ibXdXCgL0novA7UG0hq2B/RRHdX/Hid38N0fNQz+wPU2DE1wlUy573/Cz5XzJcEkTXm 5M4o8hZ7B3I45EfjLAfJFwTvODupEk7b5b5i2AhPzGMV8nboQK3mOx8P4pFuOk5qe2U55p ZE+ZYWliI9MkRMsOHY2acTqmwDjmEAs= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="X/xYmjcz"; dkim=pass header.d=suse.com header.s=susede1 header.b="X/xYmjcz"; spf=pass (imf21.hostedemail.com: domain of mkoutny@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722553041; a=rsa-sha256; cv=none; b=Y4opQpeHhFXpjS/RDnEelFy2XjOtSch7d/8omQDaEnRXcxCpqAIAlAEeq0EW+RLgxr9eQZ 2MDMd7ZWOqL9mbvBEQqqndESdUFBwFMzQ4fvbm3SYr4nB+YCRKJ6L9gUonGTVELKNHgovx Qmyz+R5ez+bTcfheEVY/NyYmYBbLlkc= Received: from imap1.dmz-prg2.suse.org (unknown [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-out1.suse.de (Postfix) with ESMTPS id D2C1B219BB; Thu, 1 Aug 2024 22:58:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1722553084; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LrfpBRx2OlghlnQUP396vQ52rxWepmoXbexqsA06Cq8=; b=X/xYmjcz12jbl5/3YVMkSKTgLyyEi3dLakZekRU8pFzCqX1AOhXVox/8GvaguOEXbiMwRj h2f0lbQ0vn3co70X6VS421xoReKL7V1xM/g6zmOAUHINYcMX4M3iD9Htr8Yt71Maer3tB/ bFxqQMIy9bbVuDBYQOWGWAhSsO2DTKA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1722553084; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LrfpBRx2OlghlnQUP396vQ52rxWepmoXbexqsA06Cq8=; b=X/xYmjcz12jbl5/3YVMkSKTgLyyEi3dLakZekRU8pFzCqX1AOhXVox/8GvaguOEXbiMwRj h2f0lbQ0vn3co70X6VS421xoReKL7V1xM/g6zmOAUHINYcMX4M3iD9Htr8Yt71Maer3tB/ bFxqQMIy9bbVuDBYQOWGWAhSsO2DTKA= 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 8F17F13946; Thu, 1 Aug 2024 22:58:04 +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 IyJLIvwSrGYICwAAD6G6ig (envelope-from ); Thu, 01 Aug 2024 22:58:04 +0000 Date: Fri, 2 Aug 2024 00:58:03 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Lance Yang Cc: "Vlastimil Babka (SUSE)" , akpm@linux-foundation.org, 21cnbao@gmail.com, ryan.roberts@arm.com, david@redhat.com, shy828301@gmail.com, ziy@nvidia.com, libang.li@antgroup.com, baolin.wang@linux.alibaba.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Cgroups Subject: Re: [BUG] mm/cgroupv2: memory.min may lead to an OOM error Message-ID: References: <20240801045430.48694-1-ioworker0@gmail.com> <2527d5a4-de1f-4c93-b7ee-fdd6fbe2a6f0@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="z3wr2ynnu36cbovk" Content-Disposition: inline In-Reply-To: X-Stat-Signature: yxidjnfki5cuxkhsqopiyd9mqkkfyc7j X-Rspam-User: X-Rspamd-Queue-Id: 724151C0012 X-Rspamd-Server: rspam02 X-HE-Tag: 1722553086-70340 X-HE-Meta: U2FsdGVkX1+wLX3jC+t7LS4EW10JYpnbhwWJk+E0U1fySp48y62IilJU564AKC25e9D2trAq/Bs98zBWyDpq1Oyax9TbMBAWbma5LcSyPVdj6nK6z7t5mN4xe8n8C1xTwou0mXziiXpT1ThUQc0+efXvUZSi8ceRsb6BvE+mupzfKmwKdZtOs0khbiH5ur6Sq4MQzbWNsZTqYd9M+TvLop5G8EeFhN0HocPNyLAU7SH+VZgQPtMjOS4MzzNuTFpY77w3T+ZBWBHnR4Ia3cF6PAXn0f6znCsES57g1nHLzvN95UI6Z0nHY6OHi/c0cCnJfqmeMWRwqofOpg7d/VUn+mODC3BT/qmrA3WNhnOtXechDz2rUZeHWFVyYZL8w5/dJktZ69t/WFL10XjYeos43+C+z+dVj6zf4FddmnOyqcgFRbM0vcGMmELix77iRdC0co19fzElCv7OyOzCeVT5Br+EsFU8gYV3wgbsThXp6BvLcbZO0mvciNHihrKeFjbhEaH0cWwluqHdVlbKbpelR4dTwkvmwCNdMoxoUpQ4gkxhIp6O+vYUjyjTyZcpCZOP0zX9K3Yt2jgUbECZsSdFWvqUqj9vUFQXFowWOqO8eFbcmoAbf/TFxzXVBvdbMzTLmYzkTBMSb5+dtSpgt9uN41N6JEvtX9GOIuovUcykaysiUEQntzWpufVdCB2cLKSPEUi1J/VVzJqQS1/m/v8ntg9Wqo+EQ15bJdxaiKmcNLnIyRTVN18m52686yp6Ja6aHQEb4US/8eDCOHpRtUhXapf0BMTl5gPp53gBXJXAlwZFEaiw1vwF1ZkgdKzh/it5x06eVKFOySBSUaay3AfXVkh8Ki/8dGsBaKoDb46VdoqwKAuqSPLKfVQUmTSRvc2lGGEZtdjleaqGovbO1BqapggZYK0D/pyVeAkO2/9DeqJQ8lcoQN2rYu5E/5i5vlXa+gJGXbNyxe2lBQWcuWg a9TyEz4E 6zoa8XSTG3+rs1w9aPeZwQ9QE1ph/EXvRZJCj2IzSziahPzGhtQ7QovT940r6kHalTwpB9gZPxC8wsBYpvp7hdN1nrNrWm3b17Hnd1gk3lS0wh6dXbYxdpp9zYSThI562M1btJ94ZV1lg7/P6m7JPym5Gda02RdkDdCiCGq7B46bxe2HuEoZ+84+WYWMgXSfS8mBn8cv64iHHttuxxttvaFBdgL5OMgCIIJxNg9Ql+lC9ipRbxooLi1JhfPzMBfBQkrR4srBw+rABl3yOXAoD5cL5T5L7fduoHQBrrO5nzdrikw47AgN58R0GAenSp13uiFtS9Mvx9iWFhXqb7p6ooDt0HQhCrUOEaktBPGivcyNV2KaxZqEL/naMD+FfcEhY43BSfd8BO11bpwCo+JBYcQUeEzr0ypAdE1WLqfskktDKy7WzrQebyVAGM648UkIChOT5y8JoGrSBdtDM32t/tshHVt2JeYW6WNSc6NciQjVFk7pjZh/EGzOC1H2syMRjBCM7t/rXCeM9qEo= 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: --z3wr2ynnu36cbovk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. On Thu, Aug 01, 2024 at 07:40:10PM GMT, Lance Yang wrote: > However, if the child cgroup doesn't exist and we add a process to the 'test' > cgroup, then attempt to create a large file(2GB) using dd, we won't encounter > an OOM error; everything works as expected. That's due to the way how effective protections are calculated, see [1]. If reclaim target is cgroup T, then it won't enjoy protection configured on itself, whereas the child of T is subject of ancestral reclaim hence the protection applies. That would mean that in your 1st demo, it is test/memory.max that triggers reclaim and then failure to reclaim from test/test-child causes OOM in test. That's interesting since the (same) limit of test-child/memory.max should be evaluated first. I guess it is in your example there are actually two parallel processes (1321 and 1324) so some charges may randomly propagate to the upper test/memory.max limit. As explained above, the 2nd demo has same reclaim target but due to no nesting, protection is moot. I believe you could reproduce with merely test/memory.max test-child/memory.min > Hmm... I'm a bit confused about that. I agree, the calculation of effective protection wrt reclaim target can be confusing. The effects you see are documented for memory.min: > Putting more memory than generally available under this > protection is discouraged and may lead to constant OOMs. HTH, Michal [1] https://lore.kernel.org/all/20200729140537.13345-2-mkoutny@suse.com/ --z3wr2ynnu36cbovk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTd6mfF2PbEZnpdoAkt3Wney77BSQUCZqwS+AAKCRAt3Wney77B SdQ9AP9aLMnZx3/4HGSUidBokh2k5NVbAqtBX6zPkBFpe48eSgEA8zZyvtnuUPW8 Y0FKs+Gg7CewHbz21JQzAJSjT6d77Qw= =ij7V -----END PGP SIGNATURE----- --z3wr2ynnu36cbovk--