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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 A4F17C432C0 for ; Mon, 25 Nov 2019 11:54:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 716F62075C for ; Mon, 25 Nov 2019 11:54:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 716F62075C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 013866B05CF; Mon, 25 Nov 2019 06:54:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F05666B05D3; Mon, 25 Nov 2019 06:54:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1C766B05D4; Mon, 25 Nov 2019 06:54:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C91756B05CF for ; Mon, 25 Nov 2019 06:54:12 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 6CF9840C7 for ; Mon, 25 Nov 2019 11:54:12 +0000 (UTC) X-FDA: 76194641544.28.house53_7bfe32db22050 X-HE-Tag: house53_7bfe32db22050 X-Filterd-Recvd-Size: 3884 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 Nov 2019 11:54:11 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id n188so13662702wme.1 for ; Mon, 25 Nov 2019 03:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Xr/25bq+wf3jkO57F+mleOHynzvsdoQgi3Dwn3Vf294=; b=S1pUg8qieXu1rj2poa/rbAZFh9vu2pEbEdN58YCKhOBAVQvymSa+YJEEQ4gHV8pJXJ d7ojimgRV1ZF85k/Xa7djXq9DEnAGImm60Te4Z7Ny4dWWjVF6/ZCcVIbIi3TSitzn82K kY49mJae9BfCyksQnO56mO8nI0N82ubczIx6WBXTwk1rpvE98Jf9Crxn0DiAN9G+/ms4 g8e1qayblNk2CcZ7yC9Vw23aRDX916QpB6JCsvEp6Q4MudB7f3NXAt/nUApGGgnZIYRB 3hbn2wTfIzGE7d2WqYk9XQLAL/bo/nv3L2JusNkNRPf9RPA6J5PgL3jZlX7XYXPj3hRi gJIQ== X-Gm-Message-State: APjAAAUdSCwiZoYwTStYY/HXLRTMXN4UneQlaxIHTXHsYFJt30njDuz9 zlOlAvSSYXER30p009BgkG0= X-Google-Smtp-Source: APXvYqy+JoeN7k4s46s62t/BeZfLB0QJM5wTPn+/f02HRaYEUiETNSYtkkNghwPFIXCK3FwSt5YfNw== X-Received: by 2002:a1c:7e82:: with SMTP id z124mr26437594wmc.136.1574682850950; Mon, 25 Nov 2019 03:54:10 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id e16sm7457817wme.35.2019.11.25.03.54.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Nov 2019 03:54:09 -0800 (PST) Date: Mon, 25 Nov 2019 12:54:09 +0100 From: Michal Hocko To: Yafang Shao Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Linux MM Subject: Re: [PATCH] mm, memcg: clear page protection when memcg oom group happens Message-ID: <20191125115409.GJ31714@dhcp22.suse.cz> References: <1574676893-1571-1-git-send-email-laoar.shao@gmail.com> <20191125110848.GH31714@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 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. -- Michal Hocko SUSE Labs