From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 449B81CAA7C for ; Tue, 14 Jan 2025 16:54:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736873661; cv=none; b=Si1wX2j8GaTmibyX3vMjexM5w7BMGPyoyWfnCypvGxxZ8lmpemgcf6Kwa2r9crcIOt49qEtf/z06cLEPOK0i16omixfOnYexo6IQg+cvfU4Grh/Ld06IyH0RK8rLAeD6hGLrh7riofeCpblSoh5wqO9ThyiowNXhmTz79VcvbIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736873661; c=relaxed/simple; bh=QArxDshYBXXjPsSxBkOjDge7ebuo2qKnIT/yKZpkdfk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c5JstQPvjc6sODA2PYm6kEp5ofk5+Qs4KjbjqeUAHnu5OIbhElqPUsat4t/4hMerlz+JQQzoyas3zuu6r6tnwltTdQZqxugwnZrEiInRqJW77/GsdxqjzP/XTV3E+4xIgrMcTrMOleZFfhB0TV1o2nPtPZij5YVhVVt4/b6b4Sc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=TIg/Kz39; arc=none smtp.client-ip=209.85.218.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="TIg/Kz39" Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-aab6fa3e20eso1036552966b.2 for ; Tue, 14 Jan 2025 08:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1736873657; x=1737478457; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LsRaccHvZKr6FJzMPGUpANQeurIQy5ZJPHMSFpAg7jM=; b=TIg/Kz39NGsfDd40XUVlW5h5e5ETYRuO2BuD6fD7buF1Fo2Xa9trrTRee/0jeQB6qg TWfo+/myhOFeozAiWg3HzD0KML8LunfygVaTkaXMXLifS2OCy46IXSg89m5nKoyRQskx 1bT+Eg2ChcV3OXQpYAruXPu6rEJ9B+gijCPbAB3VCEqzsKmz98ttSMsrf0WtpmrxBHzp VkoJBiRTtwlgI34feP4KN8J7vE3/GWPR445OWKyAfQKfhNIHWY6oc9qFX9kCNw4KSXLc w9bMXBQbqLxKE0ipV6bEUGOxNG1BIY9i59K3n7ik5QOaJFDDzRYdprtXQSk2rhVksavq 1dXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736873657; x=1737478457; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LsRaccHvZKr6FJzMPGUpANQeurIQy5ZJPHMSFpAg7jM=; b=JpgiBhfOXH2H2FyXjpRqOvJDCpsae2PqULiLT9yHgWG1uZckwmoLeuP27G7fDLbK/c +eG9nnlLTQCKtWnQBgRL2bmI+DwHhQ8ogdFjz+67SuqRliSHzlMqV8pqEkuw2y0vC4t9 0OFos/lH9clTwzk5tdN5iLppruP6/Eivogqj7hpmX50GiQdy9ur8WZQ/ibkqxuKubsmo RHcDeibYAVwx91H1S+9ibrkgtbLwJzhdM6e0mo6AWiyIQARlodh3NIqUjVI/0/FVINPS dzzFX+md+jnXjUstmsqEfiHGteJBt3G6ubgpSchv2G662A+Gh93X2MBbrI/vAtgKprEu I71A== X-Forwarded-Encrypted: i=1; AJvYcCVyyHENhE43AJRa+3F17HocpLnYvRo+snXtFOnaWcBC2pJPaoQJ+9I8Qxc1n0ig9pQj7jFIv+rwB+BvHDM=@vger.kernel.org X-Gm-Message-State: AOJu0YwGzn8/DSFSJ+yEmlAibxoTmDQ6rcTIbPsEYo1FNDyyEvWjL1g7 YYE/2VU3R6MJhZCTvbowG6OeHwokUiW7inpxHY1b4+NJ7vT89kPYXwa4j7VuNgJp/mwJO7n3Pyw O X-Gm-Gg: ASbGncvjsvwmdLcmArrjFNQLy7zfWrQCga/KF3yarpoitKKMoNgE6i5kUn9J1h+QAnh bl1h9Fegm/s0dwY0ewo1Ds7n+Ct7YK19okLEL1HxGagqYlXH9z8k6byMphgCW1Tm5wJjgcFURCS ZR3+wjcxx0a9g2seaFEgYPPbxARNqQhxR00mb2t6OQJitZnOzf0aWL/Zn4l+AeFtTxsBl6grbq4 g2YdNcHKUUwMa5BAaz1OEnxLu5UnnHSg6tLeGXvIJVUxHGaQ+awzAE5iybNmMfoMCnKUw== X-Google-Smtp-Source: AGHT+IE82dJIBD1oYsvhQ/wbzxr9AzjVtFcZvJeySe4F0GuPIoDu+lt8hhocCPFRA+YHPmI6489vFw== X-Received: by 2002:a17:907:97d2:b0:aab:73c5:836 with SMTP id a640c23a62f3a-ab2ab711bfemr2444968566b.32.1736873657580; Tue, 14 Jan 2025 08:54:17 -0800 (PST) Received: from localhost (109-81-90-202.rct.o2.cz. [109.81.90.202]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d9904a4132sm6453355a12.75.2025.01.14.08.54.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 08:54:17 -0800 (PST) Date: Tue, 14 Jan 2025 17:54:16 +0100 From: Michal Hocko To: Johannes Weiner Cc: Yosry Ahmed , Rik van Riel , Balbir Singh , Roman Gushchin , 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> <20241212183012.GB1026@cmpxchg.org> <20250114160955.GA1115056@cmpxchg.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue 14-01-25 17:46:39, Michal Hocko wrote: > On Tue 14-01-25 11:09:55, Johannes Weiner wrote: > > Hi, > > > > On Mon, Dec 16, 2024 at 04:39:12PM +0100, Michal Hocko wrote: > > > On Thu 12-12-24 13:30:12, Johannes Weiner wrote: > [...] > > > > If we return -ENOMEM to an OOM victim in a fault, the fault handler > > > > will re-trigger OOM, which will find the existing OOM victim and do > > > > nothing, then restart the fault. > > > > > > IIRC the task will handle the pending SIGKILL if the #PF fails. If the > > > charge happens from the exit path then we rely on ENOMEM returned from > > > gup as a signal to back off. Do we have any caller that keeps retrying > > > on ENOMEM? > > > > We managed to extract a stack trace of the livelocked task: > > > > obj_cgroup_may_swap > > zswap_store > > swap_writepage > > shrink_folio_list > > shrink_lruvec > > shrink_node > > do_try_to_free_pages > > try_to_free_mem_cgroup_pages > > OK, so this is the reclaim path and it fails due to reasons you mention > below. This will retry several times until it hits mem_cgroup_oom which > will bail in mem_cgroup_out_of_memory because of task_is_dying (returns > true) and retry the charge + reclaim (as the oom killer hasn't done > anything) with passed_oom = true this time and eventually got to nomem > path and returns ENOMEM. SUSE Labs Btw. is there any actual reason why we cannot go nomem without going to the oom killer (just to bail out) and go through the whole cycle again? That seems arbitrary and simply burning a lot of cycle without much chances to make any better outcome diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7b3503d12aaf..eb45eaf0acfc 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2268,8 +2268,7 @@ int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, if (gfp_mask & __GFP_RETRY_MAYFAIL) goto nomem; - /* Avoid endless loop for tasks bypassed by the oom killer */ - if (passed_oom && task_is_dying()) + if (task_is_dying()) goto nomem; /* -- Michal Hocko SUSE Labs