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 7B992C28B20 for ; Wed, 2 Apr 2025 15:27:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AD40280003; Wed, 2 Apr 2025 11:27:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95B81280001; Wed, 2 Apr 2025 11:27:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FC44280003; Wed, 2 Apr 2025 11:27:20 -0400 (EDT) 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 59A71280001 for ; Wed, 2 Apr 2025 11:27:20 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 499DDC143B for ; Wed, 2 Apr 2025 15:27:20 +0000 (UTC) X-FDA: 83289482640.15.38144BC Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by imf20.hostedemail.com (Postfix) with ESMTP id 284331C000B for ; Wed, 2 Apr 2025 15:27:18 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=wvgXbCwo; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.176 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743607638; 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=swp0ERIz+E6S0fYtrVurk6RuHTXtNkHGNmb4MbsFy44=; b=Y0EtNQz0yisvdfxXFcdvelgxy5O6Z4mfDIlBF1hJ5amLbT0ywjsBZPAw1esc2ULTLELKQP AaAAckte4cDpuTJZqD/XeKYB2i3S/V2d8zFeoXSye1i4Q+3pp7FxcPAkKmLpviflnBkfSs eouuOHqeZU/kJPREUrWwHqZNMvRW6mo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743607638; a=rsa-sha256; cv=none; b=kAbD2xsHlVK+Yr/5GRt1lqiv9HQG+5Qk4oO5cRzoY6SnxjMqQGA6KrXYuCJSZvV7i9kSCM nxup0sR3eNgYM/YzS9XNcZwmLeQx4qDNXGtomcYadsiBhm9/kMHH1UNQQCaiCUurFr2oYT Q2cDI4YiIWrt2++/dbYiArrMm2E/6hc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=wvgXbCwo; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.176 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-7c54f67db99so98859785a.1 for ; Wed, 02 Apr 2025 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1743607637; x=1744212437; darn=kvack.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=swp0ERIz+E6S0fYtrVurk6RuHTXtNkHGNmb4MbsFy44=; b=wvgXbCwocwfHi27NQg7z9P4O4UtD93G+KNqc5R404uOUBEaSSNNdbfSBqHbTWu0rm0 zqtCJPrr3WHT0OSXSuXWKS1Px9D18jmQKnS1D19I5k09j40SDkjlGJCtucytK9qTz2Df EDkw3LsMFrbC6Nd3GFCIeUDUv9yXhNNtxF9PV43bq/YKKuwEUCIY9fIrLbDyHsRc0E0T XYn25YQVJekr7ip2OwGu6p2yPGFLQ68T2/D6EXIrQ/8mvvsXC/7PvnXRkGlQ6Vuba3dN WeSRwK3bhDJmYrpo/BE1dudTmMMEHcJtllPe+EYEsCT8QvEedDPAgU1nFbV68UsgUFSr m7hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743607637; x=1744212437; 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=swp0ERIz+E6S0fYtrVurk6RuHTXtNkHGNmb4MbsFy44=; b=c2L5kQ0jNUni2S7lBfgS2U7SiSXwaAOfYuT3nSAtMKEQOc92WWmsgx1wG90srin9Y9 nqf4btYi9tt11+pyPCswPzHlLsDO9PrtT6LzeofFect+OBrwLDIzqi1er/pIHevHhD09 AOd5yxE3Muqu9l8OVATyIUg1OQYjWZmCm0GxSUEagJvNyH4LbYCMzWnp4/YwpAhipS3m HsRlSPJeQVAdZHhTYbn1IAp6jIOA9Xa+NT08idd/kCH5I5e4DlvV2jUIZ0vc4Xnw+24V BqS/dV1x1B3Z7GRBGW/DRN1Wqu3cUiBGVt5LU5eSLL2OIn0tbvEOOSRTW3jC3zyIYBcL DxbQ== X-Forwarded-Encrypted: i=1; AJvYcCWDvvQLriLY3bfQ85NoJ21x4xkVrt3cvAFXUap8lh+l5A3HRVeeRTQgVbJ3hD/qFXh1lf2TU3XQ5g==@kvack.org X-Gm-Message-State: AOJu0YwYOWGrAapflHjWfXx7+l/VVuz3bhn3WyR8U0N+/WJ7U+JEhKvX 7np8fbCafhmFoCyX15BAtWFscbCCmFALmpt8E40fExKUv+HedxVhFulSQCMsUsI= X-Gm-Gg: ASbGnctVitkQvxeX38Mj1hNHG43ySaSeUJpiWizpKbA7RmobbXSKmNVWWPi2lC0tOCD YRnY8YwPjUo37QqvM2Rxfbaxqpvy16019Bp7+Hy5Bqgh7jYi9OCNn51+jqw9AVOpWLoCzMDOHCO ujQSEK6RNrvLnTSTUxjFrun4V8LldGQuoRAEdu2n1P1NE1JWQWkzHp10TT2tR+wAPP/kx5+n9FJ z1PPdTzuLymSM3yhDL72RDgmJzr8tHKkTIdCps+VBPwQnTN2oKCMsE4gFgJ9O3YKTZ4y7gHexgD KMf7vSKPtU6+BXzgiTBn/iQwiKiE+OSR7qpAIMxDsDg= X-Google-Smtp-Source: AGHT+IHJsyMfk1EJsf13VfMIMZgUAxHzVAUrgG99uJym7wCUyl4f8lI2YuB3eaEGFaakifl2T8iN8g== X-Received: by 2002:a05:620a:2806:b0:7c5:e8c5:a307 with SMTP id af79cd13be357-7c768236b36mr334604985a.9.1743607637061; Wed, 02 Apr 2025 08:27:17 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with UTF8SMTPSA id 6a1803df08f44-6eec9798807sm74840846d6.116.2025.04.02.08.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Apr 2025 08:27:16 -0700 (PDT) Date: Wed, 2 Apr 2025 11:27:15 -0400 From: Johannes Weiner To: Michal Hocko Cc: Andrew Morton , linux-mm@kvack.org, Rik van Riel , Roman Gushchin , Shakeel Butt , Muchun Song , cgroups mailinglist , LKML , Michal Hocko Subject: Re: [PATCH] memcg, oom: do not bypass oom killer for dying tasks Message-ID: <20250402152715.GA198651@cmpxchg.org> References: <20250402090117.130245-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250402090117.130245-1-mhocko@kernel.org> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 284331C000B X-Stat-Signature: iho5sg4j1yijugw38nyxt19dowm98zzi X-Rspam-User: X-HE-Tag: 1743607638-495071 X-HE-Meta: U2FsdGVkX1+VOB93aaDcgmN1wGgAwQ9lIOz3lUuCqF6YHzZwJsgocHCvr38rykWLS/ZwfFsiG29zLBLSGudM05oJfbCXSh3tiYdYWTDCGvQP+kT7bYAYheZgssWNbNXifjchyyyDCeLz9rA4PmLqFUcTHEkaSIoWLmLDIhug+GQb+qnggYhNhrpNJqvgLiWBBuyGLeVT1PqN0/M801Y3ZR4Fz5oJ6+MJdI7BTiOKOGVrQbXyFxEUN/CHKEtx0tDrTTM8p5pIN9SOxVP0wpfEIJoQkQxIBfmfWKtqnvGiEYPH3vDOadzqKR1vAJRB2HZ/ss3lqmouvBv6p0ZJKWWt/s/iEpomTX7GEIm+8CnN2vPFB0lYSPlxtxY/CCNxMeIfmlb3tuz5LessU43Gue9CSinpHgE3I/SYqh/hbuxqCs9GHRT7wBWXTaHmqCXClemNPIaY1vw1O0Y7w3kokl1iUv1Aj6ihOoyN8Hu42Z972XDfv0uAV5HIpTkEK9K0J+rwJHKx/XT/+BuvowoTYyLkCaP0Mx1Bz+bsrjOx3LCujVUw3aV81BTkOR9TyH5hBHY7NFdfx0o5B20AXd/clOVSHXah3QB+Ax2HfQjlrk+RRZRAHN8TdfoXbloifg3i2n75Bdcsyr5gWcEKmsF124deG8iIN9iYK/3nbSF8OYIwvBdyihktPv064pHUr2gFjAosd2TNHy9ghoo+kAjNS8SHmbOM3vfBB6pj4Dgxmw127AhpsjcxaenXfaYa/BSqNsApbWscrve8ZT8D99s2q6f27w5QjFAH/6t2wGI9tSCwyc0HmrTrSv/hf+wUyT2BtyQ5/9pigpZG12JJfjsyBZhVzzW53DVjpPA+bXOfC+oWlHq5xGuzSJPfno+M1u6+K57p2OcFOcZFHLHWAwnuXaRl/5dLJttqFXazXr/z2gV9NTzNMqwJ4GocrhSLyxPFd68YxXhFoIzCzAFh/83c9ev wRZES8zS nNFoRziqHht/bk0MsGjY77UEY77LQbz37g+CBfdDP5UAt6Fiw6+doyPZxOoeNF5I5u4TqHpXIC41BVcwGuMqRo1kZI0//tZ8QA/AoE8NP477pQ6+KBsuu0g1aC43T4XfvJlYQjxSQykhOPr+ShyMXqc0nmp1gLoS4X9ZAwsbUjtsq/0j8ebQZh1G+AxW/lbau+ZwteukziuIgcdQV/uuqquymtn+QyF/WmtyOkyQLWHnW+ElDen4Cv8tygtBdZTg8lzSRWxbHYUtPDCyZt5x6ycfbAvHyKf+pBJJ6yQZHUDFi4YeYwpb1H71Q+3Hm4NfUyP8QUUJxpI3bjKL3/C4YbKu3jWxRXhuwywqLis/LowLhMiulDvFb6V2DtyTb6+S3Q/ki1c9mUEx5ypu1/qXwWVlNubdWTSjAxU8/aPlzQlEdoBQMmvCEVYOKLyh7nvkBY4EljqaEQLPRM4f+3NQN5jh+Hi0ASNcQCf2QDU6Q4wzCYsPXjEEgeanTkqTAEfrxeSjeeDmkxLzGdTcgZMQNBUh1yVAdVnYvMBbIoMJ0824F0muFy4sAsuW9NaWNLk5i+W0M 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 Wed, Apr 02, 2025 at 11:01:17AM +0200, Michal Hocko wrote: > From: Michal Hocko > > 7775face2079 ("memcg: killed threads should not invoke memcg OOM killer") has added > a bypass of the oom killer path for dying threads because a very > specific workload (described in the changelog) could hit "no killable > tasks" path. This itself is not fatal condition but it could be annoying > if this was a common case. > > On the other hand the bypass has some issues on its own. Without > triggering oom killer we won't be able to trigger async oom reclaim > (oom_reaper) which can operate on killed tasks as well as long as they > still have their mm available. This could be the case during futex > cleanup when the memory as pointed out by Johannes in [1]. The said case > is still not fully understood but let's drop this bypass that was mostly > driven by an artificial workload and allow dying tasks to go into oom > path. This will make the code easier to reason about and also help > corner cases where oom_reaper could help to release memory. > > [1] https://lore.kernel.org/all/20241212183012.GB1026@cmpxchg.org/T/#u > > Suggested-by: Johannes Weiner > Signed-off-by: Michal Hocko Thanks, yeah, the investigation stalled out over the new years break and then... distractions. I think we'll eventually still need the second part of [2], to force charge from dying OOM victims, but let's go with this for now. Signed-off-by: Johannes Weiner [2] https://lore.kernel.org/all/20241212183012.GB1026@cmpxchg.org/ > --- > mm/memcontrol.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 7b3503d12aaf..9c30c442e3b0 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1627,7 +1627,7 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, > * A few threads which were not waiting at mutex_lock_killable() can > * fail to bail out. Therefore, check again after holding oom_lock. > */ > - ret = task_is_dying() || out_of_memory(&oc); > + ret = out_of_memory(&oc); > > unlock: > mutex_unlock(&oom_lock); > -- > 2.49.0