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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7813C432C3 for ; Thu, 28 Nov 2019 05:00:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 75BC7215F1 for ; Thu, 28 Nov 2019 05:00:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JO0cJ10M" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 75BC7215F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0D5DA6B04FD; Thu, 28 Nov 2019 00:00:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 086986B04FE; Thu, 28 Nov 2019 00:00:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB6606B04FF; Thu, 28 Nov 2019 00:00:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id D2BD96B04FD for ; Thu, 28 Nov 2019 00:00:33 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 735B8180AD807 for ; Thu, 28 Nov 2019 05:00:33 +0000 (UTC) X-FDA: 76204485546.04.rain50_21eb9d7015649 X-HE-Tag: rain50_21eb9d7015649 X-Filterd-Recvd-Size: 5428 Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Nov 2019 05:00:32 +0000 (UTC) Received: by mail-il1-f196.google.com with SMTP id b15so51661ila.7 for ; Wed, 27 Nov 2019 21:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=orxE4pe0MGIN1Wmly6cNqm1AaNVVH8CXa84Wmy7l2N0=; b=JO0cJ10MKVU7GCZy/DFkmQbc06HEPfxGMUP8OEtLNw5Gi/FZWj7jJGWQEoWZN+UzCd pksjEiSfIMSbmAFN/rveTz+UCKLqh7MlgOcRE1161O2SgNL7ebhVytwPRgSwtbt4ZCHG tVkoX3yBNv7UD/kzH4TfL9Y3VUmTgT1AEa5ga8dNJcPPO1Jva0BkJk6yAgcLTxY+RqsF RmGtOHNLuydomWH/1hVkmNnJQN6czUhZSSv52b+5o0CnX/Mwqlk5w7ZXmy9Pv0uGc/rs xj6DGqL5RrcXLyrSuwD2BL4pUp/97kven0ZqAOWoIs4ONUeir0ieYXOd/uXv7Yh3dvpq cncQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=orxE4pe0MGIN1Wmly6cNqm1AaNVVH8CXa84Wmy7l2N0=; b=Mjnxa9khJ7xk4QWeaoLVLAopgPcMJxVmG+2nl1GDnJGQXlO9DimYTUM+NHcHqF0QkI iiicnpB1+NCcGnRUHcgYovNX7Hk4Qtrh6mPC0EsL+KhQLjjQIKZX5OB/biOiED5Vtl/V U9BuU1W6HG1nMyA7I+JYW+asQtZNZ9CK7E+d1zvS4Fu4T/kaMgshWoqeB8UZt/23aPMF GxGk1N4PbNdq6Tw3NM1JZSM05eSnt1PnTV1o2ClgBmmemcke41AVC1hiZPTZmSCS9Zng XQhSH/Jzgu8/YBbFC3Vzo7s/6M9FC/ZA3Anv5JndQ/vdtR2uY0cu8IiQcWfAD+hkqfVF R4jw== X-Gm-Message-State: APjAAAXHgZGGflrhGvqLZvhHScEIxdSAYI2HTnh07lDrHEA5wCSx8dwb fIe66tRsCqCB/wRnAqGZf7T1lPt0iI5Pbi78xp4= X-Google-Smtp-Source: APXvYqwofu3Qzjk2FpCFR+lpm826ile1sSZzyyfaO+Y9VgFVm6OQ0SlJtCL1qXHJOxXAacMXIMWW1q62oG60RkQo1SU= X-Received: by 2002:a92:cf04:: with SMTP id c4mr26467ilo.142.1574917232307; Wed, 27 Nov 2019 21:00:32 -0800 (PST) MIME-Version: 1.0 References: <1574914633-2020-1-git-send-email-laoar.shao@gmail.com> <4807E3C5-990F-4A5E-B7D9-22357A4B2845@lca.pw> In-Reply-To: <4807E3C5-990F-4A5E-B7D9-22357A4B2845@lca.pw> From: Yafang Shao Date: Thu, 28 Nov 2019 12:59:56 +0800 Message-ID: Subject: Re: [PATCH v3] mm, memcg: fix the stupid OOM killer when shrinking memcg hard limit To: Qian Cai Cc: Michal Hocko , Johannes Weiner , Vladimir Davydov , Andrew Morton , Linux MM , David Hildenbrand Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Nov 28, 2019 at 12:28 PM Qian Cai wrote: > > > > > On Nov 27, 2019, at 11:17 PM, Yafang Shao wrote: > > > > When there are no more processes in a memcg (e.g., due to OOM > > group), we can still have file pages in the page cache. > > > > If these pages are protected by memory.min, they can't be reclaimed. > > Especially if there won't be another process in this memcg and the memc= g > > is kept online, we do want to drop these pages from the page cache. > > > > By dropping these page caches we can avoid reclaimers (e.g., kswapd or > > direct) to scan and reclaim pages from all memcgs in the system - > > because the reclaimers will try to fairly reclaim pages from all memcgs > > in the system when under memory pressure. > > > > By setting the hard limit of such a memcg to 0, we allow to drop the > > page cache of such memcgs. Unfortunately, this may invoke the OOM kille= r > > and generate a lot of output. The OOM output is not expected by an admi= n > > who wants to drop these caches and knows that there are no processes in > > this memcg anymore. > > > > Therefore, if a memcg is not populated, we should not invoke the OOM > > killer - there is nothing to kill. The next time a new process is > > started in the memcg and the "max" is still below usage, the OOM killer > > will be invoked and the new process will be killed. > > > > [ Above commit log is contributed by David ] > > > > What's worse about this issue is that when there're killable tasks and = the > > OOM killer killed the last task, and what will happen then ? As nr_recl= aims > > is already 0 and drained is alreay true, the OOM killer will try to kil= l > > nothing (because he knows he has killed the last task), what's a stupid > > behavior. > > > > Someone may worry that the admins may not going to see that the memcg w= as > > OOM due to the limit change. But this is not a issue, because the admin= s > > changes the limit and then the admins must check the result of his chan= ge > > - by checking memory.{max, current, stat} he can get all he wants. > > > > Cc: David Hildenbrand > > Nacked-by: Michal Hocko > > Signed-off-by: Yafang Shao > > Surely too big a turkey to swallow ? =E2=80=94 unprofessional wording and= carrying a NACK > from one of the maintainers. > I'm sorry if there're any unprofessional wording. I just want to make the kernel more stable. Thanks Yafang