From patchwork Mon Dec 9 17:42:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rik van Riel X-Patchwork-Id: 13900115 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 403D5E7717D for ; Mon, 9 Dec 2024 17:44:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1FB08D0093; Mon, 9 Dec 2024 12:44:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D06E8D0058; Mon, 9 Dec 2024 12:44:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BEC48D0093; Mon, 9 Dec 2024 12:44:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 696368D0058 for ; Mon, 9 Dec 2024 12:44:52 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 17F8A1C6EC7 for ; Mon, 9 Dec 2024 17:44:52 +0000 (UTC) X-FDA: 82876145814.29.ACDF2FA Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf19.hostedemail.com (Postfix) with ESMTP id CFDDB1A0016 for ; Mon, 9 Dec 2024 17:44:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733766268; h=from:from:sender: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: references; bh=MUmmN/Zpv6KLnOT54gjx8P797ygrrwb7O37BwtK+w28=; b=WTpVzTtaxbb72ksqQO3AoVU6KCIOKDBdsSBZiVoPsCVzgQOA7bEMz8XRpBLfkQSdLXDECc s1dSVTSL1IpZDRrY7gmLcGW4WG+DpHMMsvC4QB3szrToEUF/XvUuGYC+BJBBF6ECWGH2V4 USRrKT7seq3peuXSAwGgSFTLZi6MDQI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733766268; a=rsa-sha256; cv=none; b=HzII8iNtKdQ3O4YrsjwWiUwSFoeipWUibh4Gf2sm/iC6Po2jnAGgzOMPrft+hXAX7pGkTs dOj1oTYPkC5jgv1g30WGlxTAfS03iAVw0+KHgmf1o2zFJOWSgVRaMoLOgs4C0jZKGL3Rs0 GM0Vf8ehYr5KG+a94Smv29dIa4PGRA8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com Received: from [2601:18c:9101:a8b6:82e7:cf5d:dfd9:50ef] (helo=fangorn) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tKhmE-0000000017H-24VO; Mon, 09 Dec 2024 12:42:34 -0500 Date: Mon, 9 Dec 2024 12:42:33 -0500 From: Rik van Riel To: Johannes Weiner Cc: kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org Subject: [PATCH] mm: allow exiting processes to exceed the memory.max limit Message-ID: <20241209124233.3543f237@fangorn> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-Rspamd-Queue-Id: CFDDB1A0016 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: ggzec4unni156iwg5em4mjka7ecrffwd X-HE-Tag: 1733766266-631379 X-HE-Meta: U2FsdGVkX1+jMJizT/BtPITNWzVGvLKRbUGnELnmGYz0fcIXwxKfF2eSklnfE/Lo2mlvjnMU0A6nzIhpJlOAFCyAVaTctkQw3jFq9BsA3Diz5wNAE3IH8dFolz6+thb5tcVE2UHpz0fmVaN1JyBCJtPyBDO7G1HoRCBK44FtQaSP3WUlXhwSkxaISecsTCqe+Wqbn3DKDyEfSEzkUhlzUsHy1e68KZj/flPvu71Vox+OX2WkIF667klQ7g1H9H6z7jzizeKpHRtJMhPuHXdvN2RNdAGkCTKJKkSgQMq/Ak1NT9QlM2vgDWzcHSYI+jKgRvmdSV8BvNwRMgxvXik0NbKuxwOF8cd+6drG8LzLkGb52BD8RoZgkJWXQCN10+kV9WxZupAYSWJDxNxdICtYvUWhBvZrNLFGVEwpLR4S56uJLKhT8kq2wAVvKw28qBPIMLq8bGcbltcRcna+j3Vowpk9oEg51eIFzWxJAFPfWxJbQTN6LtgsoS9Kc66KUhmJE1PgLvenDYiWkjLANEqNFy3mNojgLVoaRhidVfBDQi0CUt/sQx9PnIWXdjz+f8CpRjwOPrqSx4OCPf7Eg0ym9zTCLm4nVD+JC6jVqF62bZ8uGxU66is06Yjh+HKdjjuN5wDEzirTOFxp4lPKat8I0e64ViNZU6LwJxfBZPAeLRMGLOKKUVY05RQydVJ13a4rcDnqRJTlbuUW9MOciQDWMCYOAfTfhO+EkTdcrVhn1r2qYcmZXdE1OtJgp0wF8qdW0HmT0/IVhsLRqHu/C99gLl6kZkoatiZGDGUHzj+91od2ePch727OaNjbCUOnauRgdDex3Kizfrgri/B9wbjoG1X9RvFrOMuw3HpWf2XuNF4ektvyPzjpovg3hwNdHX0xPhScizuuWFYgwmleQv/aUG6frDrgGOo8H5DgOT5Affc+wFwt7EyUMHhvzxNBVkCnxh57NAO0vPzUS8K76/C U2HWxztf 28y20T+V/8+ZggwaVfLHNQ408pSGAyaf4FCoZe4A3F5Y3tSpxXQtpdplwbp5FXfE3Kfh8t87v2B+6c4EorwCnd/+hYHHbih4cJG5bx/MIW5IFPL2LbP+0c20pzWcx28SdQNT2AnMgoaQfMhOy5NfM3RV+uXUlD9CQQEktmSynJjL7pRS5dbycghWhwfnqdomn1trO7/QXr2rrbmiL6DNZOemisUjX3VGz2C30YKdqUJrK+SEJkC4my08fcaQmHo1qSEGuQB3PKeoS3dmSZgjdJfepq2mPcnvdRgSpXaN0P6zGd+wB8ZWxm247mqquPM5lPCf/wSn7UToj0C+OIm6Gzn0bmA== 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: It is possible for programs to get stuck in exit, when their memcg is at or above the memory.max limit, and things like the do_futex() call from mm_release() need to page memory in. This can hang forever, but it really doesn't have to. The amount of memory that the exit path will page into memory should be relatively small, and letting exit proceed faster will free up memory faster. Allow PF_EXITING tasks to bypass the cgroup memory.max limit the same way PF_MEMALLOC already does. Signed-off-by: Rik van Riel --- mm/memcontrol.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7b3503d12aaf..d1abef1138ff 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2218,11 +2218,12 @@ int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, /* * Prevent unbounded recursion when reclaim operations need to - * allocate memory. This might exceed the limits temporarily, - * but we prefer facilitating memory reclaim and getting back - * under the limit over triggering OOM kills in these cases. + * allocate memory, or the process is exiting. This might exceed + * the limits temporarily, but we prefer facilitating memory reclaim + * and getting back under the limit over triggering OOM kills in + * these cases. */ - if (unlikely(current->flags & PF_MEMALLOC)) + if (unlikely(current->flags & (PF_MEMALLOC | PF_EXITING))) goto force; if (unlikely(task_in_memcg_oom(current)))