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 F0671E77182 for ; Thu, 12 Dec 2024 18:03:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2AB86B0099; Thu, 12 Dec 2024 13:03:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DA026B009C; Thu, 12 Dec 2024 13:03:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F02F6B009D; Thu, 12 Dec 2024 13:03:47 -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 5B2BF6B0099 for ; Thu, 12 Dec 2024 13:03:47 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 154E5C05A1 for ; Thu, 12 Dec 2024 18:03:47 +0000 (UTC) X-FDA: 82887079254.21.FDD6D13 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf15.hostedemail.com (Postfix) with ESMTP id 61C16A000F for ; Thu, 12 Dec 2024 18:03:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.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=1734026609; 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=jPQdNH3PBHctwjBybj16jQiseDbWuguppjje7WiHw6I=; b=FvvMbuXQi3+EITAUel3+gr6e2aRSnYxPjncV8Jm7m4OTOGoJpyD8KcN9c4nHlKpSqBuXsM 1rdrmroSuQ/ZiDUI7Ji38qS3/lLp58rP+MPIjLouhNLwp7tJ5Uy7IWOsz3XJQ92LDE3rwO kG84i89TrXJ7WSUPe0E62ItY4Qf2d8I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734026609; a=rsa-sha256; cv=none; b=8YuEgLRP1stAFw0Ic2yvLYEWVVbUEq7Ou8R+z2ffVQcOYh+0Fz1cy9HizqRf598zz8rRY4 70vTn6cGiFCmBxyk3d/h1NnXHvkVvnRYdPJ/r2yT03WD2f/oH/2Ngl7dPBNXbcZ03p7npE Ou5h1cxaHpb8FLCbLh5wmkDqvalNROY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.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 1tLnWI-000000007pC-3OQo; Thu, 12 Dec 2024 13:02:38 -0500 Message-ID: <0d9e676686db8e2025bc0c6dc2b55d17d9f16290.camel@surriel.com> Subject: Re: [PATCH v2] memcg: allow exiting tasks to write back data to swap From: Rik van Riel To: Shakeel Butt , Yosry Ahmed Cc: Balbir Singh , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Nhat Pham Date: Thu, 12 Dec 2024 13:02:38 -0500 In-Reply-To: <4oxovutecmn7mkbbmbk3rhqudilivf6fkedvmcbcttmcspwebl@fp6pv2a45x6n> References: <20241212115754.38f798b3@fangorn> <4oxovutecmn7mkbbmbk3rhqudilivf6fkedvmcbcttmcspwebl@fp6pv2a45x6n> 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: rspam02 X-Rspamd-Queue-Id: 61C16A000F X-Stat-Signature: kg5b6mu1sugxefkmcw3zisz1g8176dng X-Rspam-User: X-HE-Tag: 1734026596-278678 X-HE-Meta: U2FsdGVkX18XykKG9xPAJUkSPukR8S/2U/V7uMK4nTsVn0hnnzuKwaXwLmqq9BU6qYUSi8qpp7w1rupS4cemJp5gASqy3HbhWhhIqNifbC3modEo+PQRg2wWAuUF/4U/Cxe5rKrMLZS0qU4tnC1vG6Nys6ljdxGT/9flSJ+pJGA6uBjSBRF67WM3qQSvKLzEKz9ozhCg1GJVpnG5sd7Fm3NpeDtzRqKgodP3o683oVZbZHDzr4zC8XDc6uisbTWtJUFkRISqcZBWJfiV0+fIhctTksH4Y2gw8u4IaHWTcA+crvCUdQGCb3A7spoeS4w/6x8iC4YCDRhdONknsXP+SiVgpuH/pUbE3FSsiZeibUpMqxafIbhka503pEZmXl/o+E2BgTp8CWo8vXWlwWzu4HutM9o+XUH6D5PXBCEsM0GAJLmPCNprEnp1DAm7ekk30xlodLAVjU1Qjym+n4/k9xMDbKYakT0QlsR9/aHyEpzTQwSQEVFqtfvuCcoz0fOK4//EdnSaW29pOlD6jh1JLsMAz/4nPEX8Pr/eQ0l0mjDsKa8dtEFm+iY795FndKazidVhwydBXBzg639Q6uFuwV79V/v5UYSJFY1pdj4m1Ez3UvFzvX/gmdG775a9OIBydkuoRfzJOSr0Xaji16MWFlT96VTu9sdihcT5ks0prvYeqmjzhvHnNErpshbs04AMe+IeJYq21AtHtXFwCEMjJW3OiulSf29tBjX/x4P8MPXJ6dppZnU0DL7KgcrLZfWJWqVz78ne6bwImvR0R2Yd5mz5Cc07y2iExoVLQAm015eoJnSH75z6OxdBZbs91Mky4CSCl/xCapjtE9CzcW3ij9YjWkqn+89sd+fG8dSJA3eAuvbNEq4R0CXQRYvArIz8D1/o0wRd6NGWvjnATO4G93cOPBj3pobEzckB+ddkFm1I2QqOZgdW81p7L9AkebzlKZ/mRdivJAzXfQ65U4f SxL9GmNu maRQHR3W0i5aLsHD2+MPaXEFxFIZd8jSdmgjlC2N5WsRgLuIfLxJxV8vis0Og8m5rPYhhvnuJ3Q/P4exMyUtiiDNvxeLH22ZnY6keDAhWaSvt2+ahJ1CZvTJh/Y+YmyPhc+y416JPOXxfwmjdY2lgAs1x8juNkYQ5wl8X4iHULVnfZtFEM6vZdlPeFnb4fJvGH4o7+U3dX7VztjAzzG7ZKVSkvUSf25GA8Z0yDr6sbD10RMH38f41LdFyrBpCJQR9lB+wj7mzHQ8oFjM= 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 Thu, 2024-12-12 at 09:51 -0800, Shakeel Butt wrote: >=20 > The fundamental issue is that the exiting process (killed by oomd or > simple exit) has to allocated memory but the cgroup is at limit and > the > reclaim is very very slow. >=20 > I can see attacking this issue with multiple angles. Besides your proposed ideas, I suppose we could also limit the gfp_mask of an exiting reclaimer with eg. __GFP_NORETRY, but I do not know how effective that would be, since a single pass through the memory reclaim code was still taking dozens of seconds when I traced the "stuck" workloads. --=20 All Rights Reversed.