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 83744E77180 for ; Thu, 12 Dec 2024 18:32:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BADB6B009A; Thu, 12 Dec 2024 13:32:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 11D436B00A0; Thu, 12 Dec 2024 13:32:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F018E6B00A3; Thu, 12 Dec 2024 13:32:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CE3ED6B00A1 for ; Thu, 12 Dec 2024 13:32:09 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8AF51AEB7E for ; Thu, 12 Dec 2024 18:32:09 +0000 (UTC) X-FDA: 82887150822.23.0D6B1C0 Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) by imf13.hostedemail.com (Postfix) with ESMTP id 2FC1F2001F for ; Thu, 12 Dec 2024 18:31:42 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=IKYd0eID; spf=pass (imf13.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734028301; 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=/2P4JQ4o9LfjnGL6PW60gglUYd3I1qYkGnXHZm/hGbw=; b=k3Q6H155WW9zmXXbiMhWtVXW9tMAkyJCcpxO9tWdsmAkS5BX6tqd3uPTHPd/k/CxHI59gT QHRdMyQJ4wUrtrn1Dfm2zBfaDIBfUHCL7kaRg7JpD2YGohjY1bHG3Gv0VR046ujCtwyRqD zY8Lib5qsi9mdKYlkw8d0bGvwItOtZg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734028301; a=rsa-sha256; cv=none; b=hXo7W7mS+jTTGr09m4U8tTigK23PBXJrHWOJDyN2zDQBfBfqHOK3WimZvmIOEjKXF2zaP7 wFfOrtyjYsatvTxT1KVA6kYCWEEKKHBSTq+eIGLN28nC9xYZLVwe7oVryM4t9BMsgpG1Z5 W1GGhYJgpDKLNcAyo7nLeUNb58JXaMA= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=IKYd0eID; spf=pass (imf13.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 12 Dec 2024 18:31:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1734028324; h=from:from:reply-to:subject:subject: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=/2P4JQ4o9LfjnGL6PW60gglUYd3I1qYkGnXHZm/hGbw=; b=IKYd0eIDaH9mMFkZYywkjVap8ervWeRg7YFbQ7HotZzDWTpz5sA24oDoET4Ep68gz6K3wS NGZ7f8kcED+ALMtEPtd4VLrgxFHyNDXpSuk78sjxNRXWXEA90cwpFIvwusWhQYppTZ+1GC KjmWJumG/UmkO2oXEh0VQtcCgclVC04= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Rik van Riel Cc: Yosry Ahmed , Balbir Singh , Johannes Weiner , Michal Hocko , hakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Nhat Pham Subject: Re: [PATCH v2] memcg: allow exiting tasks to write back data to swap Message-ID: References: <20241212115754.38f798b3@fangorn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241212115754.38f798b3@fangorn> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 2FC1F2001F X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: p7stqpu59bpgsybhtogdtmfhtfay65ex X-HE-Tag: 1734028302-847223 X-HE-Meta: U2FsdGVkX18hMhcy5tfnbGFX2tU3Zjo5227ywAcuL91EfaPE+zzDqITUcf+7EA9yt3H40jRbWx5x5QfUkAANGJyBjQ+qVCWCUjsBMtPSBPJr8U4ULoeYgk41ZHZTXG4U01raVWooFa8pb/G0ikvDaNXAxTrI3sgCS19St5Ch+CHfDPYW/jV55qaVwgHTPahU8Bluv1aA7ahTqPYjewTDm6lAOMLB/aTmeiVk/6R9qp4HuCJ+n6Dd2SEfxLFz8l5KdSLD/9M+TRyes7hc+CElgzMbG18udGckHT0lMkkSBxQGihiQY5IKnrWmm9tYIbmXhrsaquigFDavd56Fv6BGHCWfJ8vlCt6QMosYYbIfzDBDSAtJO+dy8Xws08X5vBMSCqXmp70URoaydHVjTqdhICBX5TmpIhzFvV0PIGnecWBZKnY6AfItafDlwj+gSAFhoowciG7Fur/cQk8yFCyZwVNrixoRIpVG/lXph00RrQexS/Q/ndpt8RDHLjJXSUv7Z0LLnwg6pkqDb2JjZ3B/TYEFwsCslAruUn/s0Ed1+yexwLHyj9FR3QPVxEEyAkbvfrrvxreZbCghE/I4E0rqcUVDBzVDPVFM11GAVfBy/ek+HZZAIWQ3Lx7IiPNxpBayKEF0HgbEImXdEJrOcphxAYiV3e4ECVTNJlvG5A4gogDdRVIcITI2KlixchqBfLfQO5/i5h900MCph5jbDA/8l5O7CCJ4zjO8YQ0FHWY4FmsfUfFH3sZX7NJkDRY/L8g6hZNTVPHZsCZvmOI3iIwklc97Co1FzxX3M8MkDuN62jtUnQtziGiyFmTomi6RokQhxyKeNTODYL1By8damGSw9IuCERf5YtkA09iIHMaaTfgNd7XcFyTB5GalJ54+Bfg+beVK9Ow0ciD42rv7QqvM/00tBJWH2+DZuVOdAo3qWRGCDhRW0jgGbJJBs4f84yL3Q4Hj/Uu7jQFCDEkQ6V8 pYAk091I eD1MKf+aAuaEdxijxp+PtjVC1d8lX53F01+Z2YCPqjlD7yMHPZO1MpGcZK7wtvZEceoIGye93MdlLxCtOZS+rzaQjMY7kVsjt63QW03gnC8b48ccnBqkhPav1h/+/D6FzkciaX/u2g0jqbqtQ1zv2HZgWGh7WcjXm5DwthtAbACgSRJFrnpQeXzZpcA== 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, Dec 12, 2024 at 11:57:54AM -0500, Rik van Riel wrote: > A task already in exit can get stuck trying to allocate pages, if its > cgroup is at the memory.max limit, the cgroup is using zswap, but > zswap writeback is enabled, and the remaining memory in the cgroup is > not compressible. Is it about a single task or groups of tasks or the entire cgroup? If former, why it's a problem? A tight memcg limit can slow things down in general and I don't see why we should treat the exit() path differently. If it's about the entire cgroup and we have essentially a deadlock, I feel like we need to look into the oom reaper side. Alternatively we can allow to go over the limit in this case, but only assuming all tasks in the cgroup are going to die and no new task can enter it. Thanks!