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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 18731C43215 for ; Mon, 25 Nov 2019 12:38:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D2C1E20862 for ; Mon, 25 Nov 2019 12:38:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UblFPamq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2C1E20862 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 71E816B05C4; Mon, 25 Nov 2019 07:38:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CE4A6B05C7; Mon, 25 Nov 2019 07:38:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E4016B05D1; Mon, 25 Nov 2019 07:38:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 48CED6B05C4 for ; Mon, 25 Nov 2019 07:38:30 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 05BF9180AD830 for ; Mon, 25 Nov 2019 12:38:30 +0000 (UTC) X-FDA: 76194753180.13.gold98_4a2889b68bf37 X-HE-Tag: gold98_4a2889b68bf37 X-Filterd-Recvd-Size: 5983 Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 Nov 2019 12:38:29 +0000 (UTC) Received: by mail-il1-f195.google.com with SMTP id q15so14009619ils.8 for ; Mon, 25 Nov 2019 04:38:29 -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; bh=7alZo4MnamspSMbUs0DRHhgsyj5Dbzod4k3G7Fcvr08=; b=UblFPamqbTP+Q0bMLUwwA9DSv2y6ZJsIC11mennAb6Qi8qJBGuYH3dSP6fVvGWZ3aU PXBycZVFyKk//OY/07CthJY7Vlk+tZAvm/WmO9V1x5MuBtEidpvISpJhtiG2dW5/Doas djrFLJUesjfdyCB4Ep51eQkVO7dCHlOmLEMhsgnJ9N+VW0r3ewIOHTR2/EoPfjTTiJzR SNfT9I+YKSlFqxhcP7zYFk6nhXaQOpCLAF9ZG2HXn12d2z93OGAsVRvrcl3ndHFdRfBH Svg9gN3Du0j+r8tdovjyFQOnpDyfBaGJA/BCaPEK8wPRS4ULjaOoLebUbgZOUk8Gfl3s 4iEg== 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; bh=7alZo4MnamspSMbUs0DRHhgsyj5Dbzod4k3G7Fcvr08=; b=Jk0j79ffqc4DZEhbV3hzl0JcY/Moy/tWxohAFyGOX7o6nOlFJkRUJ56g4NITruE5rh EWKxzlJwk2cSGaGjllN1Pqlr7gvP6fWzcK5Zi0GbX3WR7znvxTqSjMOomqTodCpY9+q5 UhWI1PTmsLsRK2cK8+AhQ1m02BiuG9X2IBGcye+YRxqHq+WShIqV9LIrLrYXnM5LH6qe gLrHffmwkLHaqVjdk3J8QtQhfubhn/iYadX1xxGlNivBKRn1VP9pnr2k/HogKHX2EuGL YZFVqVWMiwGbM8TBcp3O40bR8uKFuwjQL7J9g8zwrZZ2X75BecD8qHqqqQp4iQMJhFnM XWYA== X-Gm-Message-State: APjAAAU16OUxLusunRBnAhPl407GnvwT1GMzVs9pazgYSM+SrwH/Wuo+ 5dRhVK50+aMcObk/EsU0mnx7sh+Zn2uahRRfJNQ= X-Google-Smtp-Source: APXvYqzCWR6T4ZMgJjOIe/YXq7bCnFggcAnr9XhCBiEkO7MciT3BtucRqqyt6iGYaInNiuV1AP5mha4zLVfYU578Zus= X-Received: by 2002:a05:6e02:8ab:: with SMTP id a11mr14746688ilt.203.1574685508795; Mon, 25 Nov 2019 04:38:28 -0800 (PST) MIME-Version: 1.0 References: <1574676893-1571-1-git-send-email-laoar.shao@gmail.com> <20191125110848.GH31714@dhcp22.suse.cz> <20191125115409.GJ31714@dhcp22.suse.cz> <20191125123123.GL31714@dhcp22.suse.cz> In-Reply-To: <20191125123123.GL31714@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 25 Nov 2019 20:37:52 +0800 Message-ID: Subject: Re: [PATCH] mm, memcg: clear page protection when memcg oom group happens To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Linux MM Content-Type: text/plain; charset="UTF-8" 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 Mon, Nov 25, 2019 at 8:31 PM Michal Hocko wrote: > > On Mon 25-11-19 20:17:15, Yafang Shao wrote: > > On Mon, Nov 25, 2019 at 7:54 PM Michal Hocko wrote: > > > > > > On Mon 25-11-19 19:37:59, Yafang Shao wrote: > > > > On Mon, Nov 25, 2019 at 7:08 PM Michal Hocko wrote: > > > > > > > > > > On Mon 25-11-19 05:14:53, Yafang Shao wrote: > > > > > > We set memory.oom.group to make all processes in this memcg are killed by > > > > > > OOM killer to free more pages. In this case, it doesn't make sense to > > > > > > protect the pages with memroy.{min, low} again if they are set. > > > > > > > > > > I do not see why? What does group OOM killing has anything to do with > > > > > the reclaim protection? What is the actual problem you are trying to > > > > > solve? > > > > > > > > > > > > > The cgroup is treated as a indivisible workload when cgroup.oom.group > > > > is set and OOM killer is trying to kill a prcess in this cgroup. > > > > > > Yes this is true. > > > > > > > We set cgroup.oom.group is to guarantee the workload integrity, now > > > > that processes ara all killed, why keeps the page cache here? > > > > > > Because an administrator has configured the reclaim protection in a > > > certain way and hopefully had a good reason to do that. We are not going > > > to override that configure just because there is on OOM killer invoked > > > and killed tasks in that memcg. The workload might get restarted and it > > > would run under a different constrains all of the sudden which is not > > > expected. > > > > > > In short kernel should never silently change the configuration made by > > > an admistrator. > > > > Understood. > > > > So what about bellow changes ? We don't override the admin setting, > > but we reclaim the page caches from it if this memcg is oom killed. > > Something like, > > > > mem_cgroup_protected > > { > > ... > > + if (!cgroup_is_populated(memcg->css.cgroup) && > > mem_cgroup_under_oom_group_kill(memcg)) > > + return MEMCG_PROT_NONE; > > + > > usage = page_counter_read(&memcg->memory); > > if (!usage) > > return MEMCG_PROT_NONE; > > } > > I assume that mem_cgroup_under_oom_group_kill is essentially > memcg->under_oom && memcg->oom_group > But that doesn't really help much because all the reclaim attempts have > been already attempted and failed. I do not remember exact details about > under_oom but I have a recollection that it wouldn't really work for > cgroup v2 because the oom_control is not in place and so the state would > be set for only very short time period. > > Again, what is a problem that you are trying to fix? When there's no processes running in a memcg, for example if they are killed by OOM killer, we can't reclaim the file page cache protected by memory.min of this memcg. These file page caches are useless in this case. That's what I'm trying to fix. Thanks Yafang