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 E7FABC3DA4A for ; Fri, 2 Aug 2024 01:56:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1011E6B007B; Thu, 1 Aug 2024 21:56:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B1C66B0083; Thu, 1 Aug 2024 21:56:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBB736B0085; Thu, 1 Aug 2024 21:56:44 -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 CC4856B007B for ; Thu, 1 Aug 2024 21:56:44 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 702BBC095F for ; Fri, 2 Aug 2024 01:56:44 +0000 (UTC) X-FDA: 82405641528.07.4F89A9C Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf13.hostedemail.com (Postfix) with ESMTP id 976352000E for ; Fri, 2 Aug 2024 01:56:42 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VDCcGfHX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722563756; a=rsa-sha256; cv=none; b=5wfQ3m5HH7cvKK7NdxWi8anVDe89dSVVTdHeOPHXGJ+5BzhaJ9EkkxJA2Z6h4lsDZInjzQ mWujD2cK5Mw5KiTGTwd8WJrMnDlYJzMvtk2wEG7V9W/cKPbGYDmKPjHPXHna/0byLC9vX4 MWIVqxRjOFqOuHdjdNOBbKiR8KDlBas= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VDCcGfHX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722563756; 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=LtHQhobldpJJPQmPYcIkiHl149A/gyJJkr05VI99uUI=; b=pMibbY4BoCFJQWnnonuodphAf+tIeyEyYIl23MRqGBoFhJSFfZ6vNGFRDZJq/KpwVKNvFO 95hgDhhzHRilzNq7WtDXBYwz7Kkj1OdayKmN7lv2g3/JPgGWKYtmmxrf6YHbLJEyqxR0IH LG+1Ai6nE+rGoRME6w3LdSgkHg7PIFs= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5afa207b8bfso8027234a12.0 for ; Thu, 01 Aug 2024 18:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722563801; x=1723168601; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LtHQhobldpJJPQmPYcIkiHl149A/gyJJkr05VI99uUI=; b=VDCcGfHX3WoFADQC5mv5cDAXymHUGuVAF1iLOX/OHGHzsxzd7ERhoGP1JArOLi0EOB GD3wwvyl4nGcVZ/WBsZUs2gvzgWsYy/CCNk07Y5hyk+MYB1a2mTctzAMVzDe4ERvDKu3 tT2jNQzwJfAFz6mHZ9pLhoSgv+705QkKftjiu/OU8wDLAhxJduQaPlqc58a4PiHQkEBR Dak86WVrvZTPwtEw9V4RW14YCQ6a7HlnEh5BC7TTB3zIi5GBZZoHvOMfBdSyDkl4xEfk ztYqujZMft2rCXmb3cXzXvasQwWHW8Ynv6dTxVb7wZ36DWPReWohgrCXDxV0fkIIoymo 13dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722563801; x=1723168601; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LtHQhobldpJJPQmPYcIkiHl149A/gyJJkr05VI99uUI=; b=wQ0NU8kr5uR//88cCPyl3bbGQAwrdI/rLeuQ/35JZQ/rwfwoAkwpBi15s0kVbTA3QL 8S0gAT64AidODlz3NGzUSorWO8F+eAYHZXBJX4dF3oPBAIP0Bd/Gbd7PWe6K+YXYtEp3 gYR3MHASB5lcI69AO7Nsvn2YRyLBKJ/oWPNgmHvT/wIaMOw+qapRsEBUuTpoW15hoeno VBfUdolDP3FPt65Ii952h0CRMULb+QrQS5yEdOOlYVfiDZFFsA9RZZ92AoLi6OWJgOlL /saeKuJLSlO6IApvORf+TwI81Y7JBvEFme7QNwWFih7mD2VfmInh3/BsI6Xd3DYKSMUa uNBw== X-Forwarded-Encrypted: i=1; AJvYcCXT/8CRV4fQu+x+mhqAcKc7H/v+mJhxuP1Q7axKO1hKmysmRjFKHbkV6UhOX7Iqt+nmQAwIfiFdFzx54bHbG2bWLbw= X-Gm-Message-State: AOJu0Yx1NVuDD63NXd1hB2OXhoJdCwf/8oeAvLgYOUMvVziWD2S/TjQV KWE1hRqcaCg/W4ihe10FcoHmAV2e0sWxLTFDTvwfvNOUAyYiIfh3/QalKCroGPii/A0yFJHbB9D xA00PPW3rXX+4nMYDMAe7ySIAoso= X-Google-Smtp-Source: AGHT+IGfpycLUw+2FFBR3cE2zymB2hyFOpnDRwpucSUMZ4M7PitiCU0H+n9vg8QOwC+Ul5yDbrfFO2+oCM03kmWzlSs= X-Received: by 2002:aa7:de99:0:b0:5a2:abcb:c4d1 with SMTP id 4fb4d7f45d1cf-5b7f56fe773mr1337568a12.34.1722563800666; Thu, 01 Aug 2024 18:56:40 -0700 (PDT) MIME-Version: 1.0 References: <20240801045430.48694-1-ioworker0@gmail.com> <2527d5a4-de1f-4c93-b7ee-fdd6fbe2a6f0@kernel.org> In-Reply-To: From: Lance Yang Date: Fri, 2 Aug 2024 09:56:04 +0800 Message-ID: Subject: Re: [BUG] mm/cgroupv2: memory.min may lead to an OOM error To: =?UTF-8?Q?Michal_Koutn=C3=BD?= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 976352000E X-Stat-Signature: cjike8syyyuf8ue7i9x6ouu41b7g19s5 X-Rspam-User: X-HE-Tag: 1722563802-895345 X-HE-Meta: U2FsdGVkX19Cq6mkiYt6ViCOTqYzxcj7eKRAt7FQIZaCuyZgUoDIb/01cs5+qICC0Y+fwNpZtQg8zSa6mwPWNmhL3nZnPQdIFwwRlC+GyeDK1EMEY3jG1B25TpaE2DNpzCr2MkDhbKxGcYWm//xo5KjwenAM0Vwtv4IpSQFTvz7wmVlElLVcvrv3EHc5f9AUvPPIMPElYtKTYB78Tsx6/e2PnITqgX7GDGo8lFN5Lj+tUT0bE0Ej+VyfBev0VMGPaX59MG4ZdEnaCEzuJOXDajxgK+WUU+HE09MLQ9hE2SIkLqtlhuxjHOMGK7RbeXZUAm+plfETaKmC+4tFd53nZN8nYp2CJnlIhKO2fkVVhc0vzIWfFICyGjIYHNt/6Y+BSTGZUS0wmIGxbBNJc9QaCUUeBTfYEFdRJG3Itg09FAb3Ujs2pmV70KKDCX15EZcJ5Ivow2l4DjVm1hNrOpKOVm5Mw18cdJpuHP2gX7sVY84bzP5AUmy2SCLhyEnigvYhbA3u4iyGjPaTYFB5fLzhLKfvpdVLv0BWDkO15DplPVaH2YJGjMRLsi51/SVyuY63iuERhrvbX4yA3XGESNU9jESC7TTuqi/sA1NHv578X21FDF4aBqsp1Zd95XD2dCTypoOxFE1aabYspJColXlViNsVw6RS6O7P2k7LdQZxhMu9683KaZbl3oUPspoUx2MFz8f0iuiFKj/VDQ4vTRQPe1F/6cW3QSBuefoV0HYLXZ10GaJW4qgZLyZ2SUkCGMnmVSTfH0C2VSzR7ysCxTW5j2hZE6XH6J+6cyx0OoGH/D7TzW2qrtMhFEI4H/kUpb06UGsN3IOO9ffDEVZGK8fFDwFvJIFU7txF7EXWj5jYLd/+6L/aC72X5itCCZpfx4x7lXDftsXhrktdbbqyiWbWN/+WVA8jcPRBZaGmsy8FYXjSBMQX94XQ9UUJigSm4rMmhxfLG6yIM5V1/SlgAHS e/X0q+D+ e/EoDHt5xdpgK67kCtWizIZqNadaGE/BiG5U1lEjhBTM+hwPRbdxbHNEiEzhEifLfoARLvcwOXUDPMk3scTIFynFxQBgOj6f7/ZDXeSqSVvs4Frm4mOnxkYhKvlJR/aqJSVh1Z2E9R1EA1QANg0cuNu9bDs3ggNKZLiOsE1wozpyQOCj4XG+nHCQQIS96SiRtw978AJmtuBw5APzJo3eozPXXkyV1VhDX7Prk/5OlRrd1WHEesUGvAftLFnmGdfovKUkHfdlnk5BOJqbLBeK5o0ZqhaBA9DTiUjJ01nhO8dg4VqbQZpb2r04FRLJi2VqKhzsKmHMBH0Ud24lobX9XG+Pt6j2UecE5Na83IrE0jLg0VzrpKew2f8ccYumyFUzzIok55nE4nKbgEfrPt+J8IhVVdIRgpxCCJl58NlMIQ4fqBT6sI5YrQ0BryuUoE3BANjMV X-Bogosity: Ham, tests=bogofilter, spamicity=0.000089, 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 Michal, Thanks a lot for clarifying! On Fri, Aug 2, 2024 at 6:58=E2=80=AFAM Michal Koutn=C3=BD wrote: > > 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 enc= ounter > > 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. Makes sense to me. > > 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. Ah, that clears it up. I appreciate the detailed explanation - thanks! > I believe you could reproduce with merely > > test/memory.max > test-child/memory.min Yep, I just tested it, and you're right ;) > > > 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. Thanks a lot again for your time! Lance > > HTH, > Michal > > [1] https://lore.kernel.org/all/20200729140537.13345-2-mkoutny@suse.com/