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 AFC79C77B76 for ; Wed, 19 Apr 2023 03:08:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C6558E0003; Tue, 18 Apr 2023 23:08:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 375958E0001; Tue, 18 Apr 2023 23:08:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23E378E0003; Tue, 18 Apr 2023 23:08:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1697B8E0001 for ; Tue, 18 Apr 2023 23:08:23 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CD3421C6635 for ; Wed, 19 Apr 2023 03:08:22 +0000 (UTC) X-FDA: 80696657244.02.63C6D4A Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf23.hostedemail.com (Postfix) with ESMTP id 0FEE714000A for ; Wed, 19 Apr 2023 03:08:20 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=shopee.com header.s=shopee.com header.b=CFDTP8Up; spf=pass (imf23.hostedemail.com: domain of haifeng.xu@shopee.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=haifeng.xu@shopee.com; dmarc=pass (policy=reject) header.from=shopee.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681873701; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tn1RBm/Mor5mDf6XpgrvR7fGB9zm/SepD40w5P+k+Fo=; b=D+oMOMsGP7HGxlrZ/l8Gh2NYJleGwVO5soLO3bXFnwKlnys8QYO+kgR1NHjenDx5wOOQzN l1k5Fj7lb0FI9lmvGv1e25lpszyJgpSVedknFwwOKK0W3lf9JfB29rTotGyi31cH6227uM vxvHw2a0gHR1gN+LqRKtS1XEewftwig= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=shopee.com header.s=shopee.com header.b=CFDTP8Up; spf=pass (imf23.hostedemail.com: domain of haifeng.xu@shopee.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=haifeng.xu@shopee.com; dmarc=pass (policy=reject) header.from=shopee.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681873701; a=rsa-sha256; cv=none; b=2JdpmBtKpWDyu6/8eiNXPHOTCBJDrSwu3GR7AaSbEKuAbiBk00ZiS+fxnwgVtrD6G7BTkU w8gTkKuZ+MWZL34tyGkt2aJPk7wm0ZEiLGxO8bs+9C6L2TSEqz3Y5jhHaGZZ0eVYy2N0p7 34HcVAuelkENKEFtB1864VHk1Yu1yvw= Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-63b5465fb99so2508087b3a.1 for ; Tue, 18 Apr 2023 20:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shopee.com; s=shopee.com; t=1681873700; x=1684465700; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tn1RBm/Mor5mDf6XpgrvR7fGB9zm/SepD40w5P+k+Fo=; b=CFDTP8UpamOjSkf6uSwJOpfoEuiWUQFQkpRmx0iuOyVqPiTd0RG1EizK+6m/2ENflQ zuvXS1EccxoMvzutlUsLWIQ0GKWF+zHw9ZIz6D87a19z3vrERVD//Dz+e9Ree6yCZe+9 S3TUoEPer+uzdJo+Bo2qfHlWJupVYHAsxFVCZfTd1AN5d6BI0RDJasSzG/Crc6HuLTz5 EGpIFM+AgVt2olBdg0YR1L+tuK/zLXOFQqCSaKEyQgHDI/bnyoDBvXAUWFbCL+g3CYv8 bxiDHUoy6ZcX98Y78K1+cx+BOoPYoNQ4tNlSu/eyRlIUpgNJOPylspmFfjaS8EL3/4jN IKQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681873700; x=1684465700; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tn1RBm/Mor5mDf6XpgrvR7fGB9zm/SepD40w5P+k+Fo=; b=HEhCsl8gB3dkkSksZr8bnvHObe2o/FLs//IyIR6N4XHP850Y0MnuhBR/kAmyIZAey0 NKnzbizqzxMMZoxq/WG25LwoHyp51FvZGfg2tyKnpWUJ5nv1WAfgLYjh1Fi4nlc4BTzu QSykGFNfNFpUpcX8wnlbB/lRfjHyD/3mxjFxRCd2r2/y8KFef9hJQCHarYYEvRbbgxqW EIoUUgY8fp1WJJxjdR5gsjr75N5WPLI0SrNa4uXOasVzRUZfunFL4910N/QYVevViUKl oTlCg5X0tGYK0Jp+MyI4zZuYp59+ObH48zVn91KmHCBrdl3NnC1OooGh3XRAso0F2JnJ nGCw== X-Gm-Message-State: AAQBX9en0XhP096VRl0UFJ6JzT4CSkI30NjvHVrEftnY33Szd59npnvk 8qRLYeUomZSdIexr2t9Xcxay7g== X-Google-Smtp-Source: AKy350asA5G5VYeryy5kXjQ+H+m8URTVhHjZnwlLzTm1vK5ZivoG1Vzfns0ISy6SAVDuEobZ1E3z8A== X-Received: by 2002:a05:6a00:ad0:b0:63d:2333:84e6 with SMTP id c16-20020a056a000ad000b0063d233384e6mr2130939pfl.33.1681873699794; Tue, 18 Apr 2023 20:08:19 -0700 (PDT) Received: from ubuntu-haifeng.default.svc.cluster.local ([101.127.248.173]) by smtp.gmail.com with ESMTPSA id n13-20020aa7904d000000b00639a1f7b54fsm9900150pfo.60.2023.04.18.20.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 20:08:19 -0700 (PDT) From: Haifeng Xu To: mhocko@suse.com Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeelb@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Haifeng Xu Subject: [PATCH v2 2/2] memcg, oom: remove explicit wakeup in mem_cgroup_oom_synchronize() Date: Wed, 19 Apr 2023 03:07:39 +0000 Message-Id: <20230419030739.115845-2-haifeng.xu@shopee.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 0FEE714000A X-Stat-Signature: mdt8wke89jxdzpurhi9a6i7yotadqrud X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1681873700-782854 X-HE-Meta: U2FsdGVkX19LjcNveMfX3o3BLQWZv1Usdtvtrx+xxye8raNub0dQjFmHEYdeHbzk7W8zkj4RqA/wdovWVfjoilmOx+oV5uoa+8prrdAg377PojIBjDjfDMYnMU2QE7AuWgDoZ6o9CcXknj8uWJ98bnHSe2ZRp8cxmmJtwumRTcpi5C1Y9n6cB+PvbFqB7Vl4HNCuh19DRfyd8QDzZgfcEWYBMfcAGOD9MkJGhHiRe/OILavCat5aym5Ct92Rs70RTsk9y+DmDImAb9LgipeJbyZCXJ1K89CaN1hZt26Sl3joD5lOVG34GDzeSoFhZP7NxIjpoYTzBYRdkIrHJuy6GMIDGbw+Z2uMAGp5RpFmdH9WmkJgz2lKPSEI0FfXoEa+3NZB1JgYYURj16TPBbAKZkOgq3TKBtpIdQ4Ag2g9mA7Owx+L85Q14YjQWdPzcZVxwAUagyws4MmIM+Fhm+beWbhoKG+n4W9VusjYm9A/CZkKNq0AJWbU8F+qRmjJUrJ9mXyFX6aQY230vJyPL/GIKX/4fqh2qcJKjeAujud2uIzLeluNrFcw9JzPi/rCqwiCeRPlkVDA6CQreUaWW30roTVkR1Jh4WRHSxnBCwpSUxKmIIYe+M4pIZ3sT4cxIHMMp+3Zgx+CXw6yjqCGFkj/NKx/Es50EkQaucaIq4HCGiDeKYudgcaUyT8XaWuaOW1ROt6dY9D1xk9daEdkgCGWs4esmz87aFP4WZ438tLBnGaQHc3jERhfxry3hh2v8laAajW4WY04AroSSmGV6NTY9vriZvY91WqAlrPUiAnNqQIHBSpexSz6F6zXO2UEOzkht3SrszoLLgrC1YN22APCpVOzf7SpDX6LyzwQtP8j2Tl9HRKEFkPl9GW9SCEmJm2heaRtpMEqVni+T5KaGUwQQAJdcHkOg7bKwPYz+ad5FHtSKvlRxKiCefqSWHDTEF3BQ5leH6nEjWp6g8JKt06 ZU8wPuuh E0fJ88MaqzmcWS6c72nHGSpVEqv6LXoqZl88As7Hp5MS6pXuCDF/s3tYxNPVbWOwwodeAp7qG/xfT+8aeYF0UmaYW6KYucQGqamkMQWqymaYFsAV91tQys8g8gHGELXHCvwH7YTKPY8AWOjT7aZhOalGZRUKfRW/MkZtfDEdX4HAE7+RdGC3H8U3TYuCcNmRyObu0jDfzFqxyFxvnNFKAYjfbInZiMTi8Rr3l3YgRlk90ckDtxgHqGcbHHQjE5cVfKp+M7IMHEoEVX/MTsCiLmqaYTF4d193I7MtQvi3nLOsELgkVjRHRifMsIcYa/vol0sChGo6zwrxhNzdGJub7sHiSdk08Paitf203OdruUuqUuHhe0Jfahc7jh/fq7G14Wo186bSLFsiMU5cQH/+/CPHO1Ak37xgJGaIXN72GTk+MC2FqXVfNTmiJBa8MtSf0HeTLpjRFvW47hd8ZR+gZre43gWOB33ted3hHGj2smYqXYXDxgqimIZcmEir/pEvzdDI3J+ahr6+5KkNXyLujR3YZDQ== 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: Before commit 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the charge path"), all memcg oom killers were delayed to page fault path. And the explicit wakeup is used in this case: thread A: ... if (locked) { // complete oom-kill, hold the lock mem_cgroup_oom_unlock(memcg); ... } ... thread B: ... if (locked && !memcg->oom_kill_disable) { ... } else { schedule(); // can't acquire the lock ... } ... The reason is that thread A kicks off the OOM-killer, which leads to wakeups from the uncharges of the exiting task. But thread B is not guaranteed to see them if it enters the OOM path after the OOM kills but before thread A releases the lock. Now only oom_kill_disable case is handled from the #PF path. In that case it is userspace to trigger the wake up not the #PF path itself. All potential paths to free some charges are responsible to call memcg_oom_recover() , so the explicit wakeup is not needed in the mem_cgroup_oom_synchronize() path which doesn't release any memory itself. Signed-off-by: Haifeng Xu Suggested-by: Michal Hocko --- v2: split original into two and improve patch description --- mm/memcontrol.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index fbf4d2bb1003..710ce3e7824f 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2003,15 +2003,8 @@ bool mem_cgroup_oom_synchronize(bool handle) mem_cgroup_unmark_under_oom(memcg); finish_wait(&memcg_oom_waitq, &owait.wait); - if (locked) { + if (locked) mem_cgroup_oom_unlock(memcg); - /* - * There is no guarantee that an OOM-lock contender - * sees the wakeups triggered by the OOM kill - * uncharges. Wake any sleepers explicitly. - */ - memcg_oom_recover(memcg); - } cleanup: current->memcg_in_oom = NULL; css_put(&memcg->css); -- 2.25.1