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 D3AF2E7717D for ; Wed, 11 Dec 2024 16:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58AA76B008A; Wed, 11 Dec 2024 11:28:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 53AF96B0095; Wed, 11 Dec 2024 11:28:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 429326B0096; Wed, 11 Dec 2024 11:28:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 25EBC6B0095 for ; Wed, 11 Dec 2024 11:28:57 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CE876121261 for ; Wed, 11 Dec 2024 16:28:56 +0000 (UTC) X-FDA: 82883211600.26.242ABC2 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf18.hostedemail.com (Postfix) with ESMTP id A363F1C0004 for ; Wed, 11 Dec 2024 16:28:44 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733934524; 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:in-reply-to:references:references; bh=OQRzu+e6XwhsooUrpJyOmagNflsiCNtMo0gU3jCRydA=; b=Z9lOMRY7Q1hH9i8A48w+Oof+wdh0ytNdsGhXOn6wPoI5J5MYSbkXoCZOjMgW7atsO8TzP3 7BJ13o+YRbFNjhEsBnP4OySPXh5Zhj6XgbFcYEaLR4v72BWwnKYeePDdcokvpnmP+eAIbB y6vgeCG1FhFVmFmc0WPYq6y6ImGXfSA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733934524; a=rsa-sha256; cv=none; b=k+vNnRo4MIH74RMfio2DW3A6dgrqfpqJXv00EXBRbGykHaJ4WK2nbgUA0D5aKbJMoHLvzh ifZTFC0sXUGMz0Btj2mK4ebN7rxYGjU+oJC/dmEjoTNkKXJW+NgMBu014qtet3r0Iyv1kX c/CiBnoIh/reQoxooIUOKKT7DaXmvOY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tLPZU-000000000Vm-20UB; Wed, 11 Dec 2024 11:28:20 -0500 Message-ID: Subject: Re: [PATCH] mm: allow exiting processes to exceed the memory.max limit From: Rik van Riel To: Michal Hocko Cc: Johannes Weiner , kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org Date: Wed, 11 Dec 2024 11:28:19 -0500 In-Reply-To: References: <20241209124233.3543f237@fangorn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) MIME-Version: 1.0 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A363F1C0004 X-Stat-Signature: zjahgxcjrjmuza3i8aojj69rwmt3omsf X-Rspam-User: X-HE-Tag: 1733934524-565271 X-HE-Meta: U2FsdGVkX1/wkR9M0EbJZitpcHIbH+tUkkz38AbydF7cNF8+Vp/s9vEoD7zl7jQtufeiDwqz7w3dLRzFqPZfHnplCvt3cNYX6KXW6IjJ+FlJVow5tfPAXXmjXJlASP02iRGdpeXZzH25bduKLUanEVevJaQiCzKvfBPtMqamqNN3ih487j2EMGpDco6EX5zyvsnPY97N3PoseEKINCWBm7sbDBaNgOYzSFdjno8T/ZaHTqIhDSL/8uvFKpS08nqwpU1Cevc6aAuzK5fyujfSKBpQq/zPqvQIoRp4idoW5YduGmLavfmxoOLQcZ3SRQl/0qicd+ngZqBYP2M9slFYqllW/4fl3V0IdLmFUEzqvsi+d+9v1ZnqzdaW4VjXD7EfJ6basoS/4U5VuzEnG+Ce+Z8W8EkVolRq9beEYlsvyjKsGPIWG4EnQLE5Rd51A6g+fYxVBdCjIfnLB1ud4lPr7h4UMmAQkcvULluUFCANE10kqa6zR8r22JxOlc8P28ZqEqH1PT64J+GkIardLWHM0FjJI3Xz9I7Tcdl3Tg9WXsfIT8ABU3GYEmdZKNk7xot5jxcxBAyuCWAGy0F6aQqpAsZZmGHRP2qQTVghA+0Bs0AqTDhS/MWD8aTFMCMjibaicAHtfL6elRfpmV62kAULBcVkOmATQbMcg6FyBVobQBYMDbpu0bqvHcZfh/b+1glAo/ZmDTNQhD9otaVqTmSY8pwN42bIyWNUHVTkddLKFngR/IBNfNur1vxRQLfk7s8agoAvprO18t4dX5atf2xEXExXixX842bqnj2CQvC8V4ptfZ9MM9wDZGL0oqC7PTE7h7fwV4ZwoLxQ75ERl9jQbVvtHmw+pec4YYGgJJ/1lFDiJ+6SNWWYiTAuOtVdzFY+t2Ns5Jt5CuxJxFSv1ngUwn4qFqEuGIZxZuKaK+xpxmimHzUXZdXUpkAXuVaVxlStlwJCMdh20rV+WE5vx2l v5zdMhbi NdGwx8lGgHarPspCv6IaQBLu4rt6Oa+zkDqZuLxJf89tFgGoNGUUFu/xvVRt3dtR2XRlfzCaMW5a6cMv7ctiQOu2d1cfPfUqtMUp3+/MdwvhPWFtiVns+oOdkMdvcxDv2ROVXY33Cb5/kw+4uBMzDNMrlZIuJGd1kBDkaHxFCi0nFiBlrxSxYk/vRpy4qZouY5OCibRj82FPMvEJShNR4DgHnh8yMqAgQPG/FpSGckS/1k+4MJAEnTft+8a1Ll31MTCcmmcKOBWCjvK7ww/AJNR0ui3iwh1SWvG973//b3At8zXN39ccBeTF4u3FWyDIm7mOc 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: On Mon, 2024-12-09 at 19:08 +0100, Michal Hocko wrote: > On Mon 09-12-24 12:42:33, Rik van Riel wrote: > > 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. > >=20 > > This can hang forever, but it really doesn't have to. >=20 > Are you sure this is really happening? The stuck is happening, albeit not stuck forever, but exit taking hours before finally completing. However, the fix may be to just allow the exiting task to bypass "zswap no writeback" settings and write some of the memory of its own cgroup to swap to get out of the livelock: https://lkml.org/lkml/2024/12/11/10102 --=20 All Rights Reversed.