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 EAFACCE7A88 for ; Fri, 22 Sep 2023 23:22:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 714766B028E; Fri, 22 Sep 2023 19:22:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C41E6B0297; Fri, 22 Sep 2023 19:22:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DA416B0298; Fri, 22 Sep 2023 19:22:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4F2336B028E for ; Fri, 22 Sep 2023 19:22:33 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 222E5B46F0 for ; Fri, 22 Sep 2023 23:22:33 +0000 (UTC) X-FDA: 81265809786.17.DF3F24D Received: from out-209.mta0.migadu.com (out-209.mta0.migadu.com [91.218.175.209]) by imf29.hostedemail.com (Postfix) with ESMTP id 417A4120007 for ; Fri, 22 Sep 2023 23:22:30 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=SpxHInxh; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf29.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.209 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695424951; 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=0Yd5FAYRp2gWhAoux+J4rXbuTHxCOAELJy5W8/YW14E=; b=jHns8M4z07XjjB22PlVVy5kxsZ9X7GhiCRBLHe/MCEyUc040g4YBoiC8c2IhpvIWpNzglZ qrDQperzPiYSI9wmU3KwczlOA9tLipAvT4OEA/2rHGva5Sva3BAtPiFj+9YKkpQ8eOzal2 Q+wxiJgg3jCdcWrK+Tyxn1YsO2OEePs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=SpxHInxh; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf29.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.209 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695424951; a=rsa-sha256; cv=none; b=0UqOyEtKAd+Ndy5sHsNO4UE8P0fYAh+ytVmV9+uF1/IDcVssJHH9uoqL0yHrpdR8RysD9Q w1KsvsZmlxcalZAJoLE4h+09otWbwXMt8EJFkbsIsWTKEyRR7z6TsXGKH0myH4ywejg5DH St7Q+XxmVr+nXwjD3FTPekHxfjmyFlI= Date: Fri, 22 Sep 2023 16:22:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1695424949; 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=0Yd5FAYRp2gWhAoux+J4rXbuTHxCOAELJy5W8/YW14E=; b=SpxHInxhdJoSkVJUo8IGgUe0T+xeuNN/TwfobKv6NiHAwLsdG8y1Y7g7X+2NNsUrtNDvEF KWX9a/mwXDZt6d7i0ga1Kyily9Clp8bpc23e6KTYoBISUl8//BqxkZz2k+ILhW+gTIfOc4 yOr0z/NNYPOR5SKg4wCaICwa8fC0JXU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Haifeng Xu Cc: mhocko@kernel.org, hannes@cmpxchg.org, shakeelb@google.com, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/2] memcg, oom: do not wake up memcg_oom_waitq if waitqueue is empty Message-ID: References: <20230922070529.362202-2-haifeng.xu@shopee.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230922070529.362202-2-haifeng.xu@shopee.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 417A4120007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 17wj5wjb3soz8nyb3t5ewnjq4dpzrs7y X-HE-Tag: 1695424950-664495 X-HE-Meta: U2FsdGVkX19w3ejCaoaNBHFONh/o5nx5jsKXflJHdUD23VordhNJcl8kEpST35RWTTJ3mibbGJsvNEp5qjQq+y4pP2QEgk9nJYdVypNoNDhpiVt+6CA8m76cxog37jpFq83keCPPsJ+k3L69I7b9r6M2zUUENKBpSFvTRP53xO3fOlMqjYfD+Q35Do+/U49vxm4g82IrE2KaqaQ3VXa5ZjmAVkgomMwkQOjxu4cVBv31+konW393rFHaymy0K/Wza6JOAxQJqxT3J8sPYTJVocUMG66cyVfIjat4NIrsV67y0MO/yu+OFfZ/AeENO61gZ4iHgvIqbv49OrSfhuO6z3jiF9Sx62kg1Csx//uZCSWB7JqZ80goO829yOY5cx8PCx6G1n5hFXGc6ERS27Bmc41vUzxBH/7X6FUigWeT9i0dkdWrfK4+Xx4/wVrE38F2kC6C8cNZidi4I48cNRHY4jsNifXVZXIGW5eJzGOXkScaK4isiAf0lsOmBZ2M/rfjsDyzbvVhrlMLwZ2ml09pg9j6y9ktDvmFomMx4UDoa1/VgGpoPa8Ubp5BaSevGZU6Bsv51nUTM3KtJ23MN7d4SVs9SaiVnKBfR8kUtmhpoxbdEfxaUC5cra6TDk2BrMTI3yB3acSiG5Yywc4XqN2KMa6ZL8CnbKYSZRmP3mxrz87VZPEEEh66deGE4JDrfhPd1vpj3ev/6ILvsSkhzOJZHPGx4iQOSntbU/GQ9f85m8XvUaNFUnlf/MRsnhQ3EfY3YlKc+f1eRYxuTQgLH2UAwIFGD8WRCWW6UMMJhl5R7rQlCgRQzXX3lmBcX4+1MItAreIAhN+n3X3u0ZLSGJaozZwAnLrPNUJkqTcuxeKC1BwyCeAf0q85FNq07Tfa7mj5dtYWgt4zchJYOOYDDCG71hO3NBv+++1EZ8/06x9mdafig93Na8G6wbToQI7ErVZyikhsSmPxD8Wj7JrFL1u JPI3+AV+ sC4R2Vb+jMnkqKQtTPrRie4jPymkxWqCqDtLxmmevIaqjYHtUTf2ujl25tLcmD5h5ymq9wvAM+PxptnI0PBDZMojvldhjRC7gDZbb7tVXvDnMO07pW+nr6dMbkO1colOa7LV/R6kpXhG29g/vMXKioVduLnhE2N/6gq3guI4TdEFMUjDEplZJ6+PCTOfS/83Ym4o+1a8jm3Y9DSnZW8L8Up6TaSoz1PjztUH5jt9jvhUqpAU3YTqFpgix4w== 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: On Fri, Sep 22, 2023 at 07:05:29AM +0000, Haifeng Xu wrote: > Only when memcg oom killer is disabled, the task which triggers memecg > oom handling will sleep on a waitqueue. Except this case, the waitqueue > is empty though under_oom is true. There is no need to step into wake > up path when resolve the oom situation. So add a check that whether the > waitqueue is empty. > > Signed-off-by: Haifeng Xu > --- > mm/memcontrol.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 0b6ed63504ca..2bb98ff5be3d 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1918,7 +1918,7 @@ static void memcg_oom_recover(struct mem_cgroup *memcg) > * achieved by invoking mem_cgroup_mark_under_oom() before > * triggering notification. > */ > - if (memcg && memcg->under_oom) > + if (memcg && memcg->under_oom && !list_empty(&memcg_oom_waitq.head)) > __wake_up(&memcg_oom_waitq, TASK_NORMAL, 0, memcg); This change looks questionable to me: 1) it's not obvious that this racy check is fine. can an oom event be missed because of a race here? why not? 2) is there any measurable impact? it's not a hot path, so I'd keep it simple. Thanks!