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=-1.0 required=3.0 tests=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 DD329C55199 for ; Mon, 27 Apr 2020 09:40:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F2B5206D6 for ; Mon, 27 Apr 2020 09:40:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F2B5206D6 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 EAF998E0005; Mon, 27 Apr 2020 05:40:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E607F8E0001; Mon, 27 Apr 2020 05:40:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D75878E0005; Mon, 27 Apr 2020 05:40:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id BE3818E0001 for ; Mon, 27 Apr 2020 05:40:09 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7ECBDBBD1 for ; Mon, 27 Apr 2020 09:40:09 +0000 (UTC) X-FDA: 76753138938.13.sheep12_3b8d5701c114a X-HE-Tag: sheep12_3b8d5701c114a X-Filterd-Recvd-Size: 4251 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Apr 2020 09:40:09 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id x18so19695944wrq.2 for ; Mon, 27 Apr 2020 02:40:09 -0700 (PDT) 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; bh=D5VnH8Swr2wXVkb3GE6FJsVN6cmyD2+PcD0tkKAKF6o=; b=NkU7rZ7nwrAj4nd0NAtM8UnwzHGTBaspn2wEdXldMoMfw0zxEgIKbFnthYnfsZBBNk nyY3WEt8DZ4lCJLeTSJr5IT6ErM6GirES98+/J0k0YxKZTRvQG36hyNl1NPMd2c8BAlJ Pt5FyYZzEODI8Ey3JtHZagGYs15aDuL+J6AA/J+3v1eGHPLNQRIQqmH4/cxOTEpupsWP llJtR5Y4pRa0dAhN3FiTxv/q7pYMsU12YbWhtX54eaSXoHczwOtz7o4c/Jl/sank9wsE CrQIy1AfHMqqqIHka1S8zwX50WaQA2lYrsttTyLlW3XkXm8eCeeb4ishvByVuYEsl42s /AEA== X-Gm-Message-State: AGi0PuYQEWOHy3j64YtYL1uNwow0pCdFMXYvbA8Iu6X6bDDF9dqFQAgX 83IkygHyfAjRS48i/34jcwY= X-Google-Smtp-Source: APiQypJFMzJtJOKc985ifFCKyn6g/coOTC56qdfidBXMEgUll4Mlh6d9SGBhiXPfUHXXOX8FlIRsSQ== X-Received: by 2002:adf:f748:: with SMTP id z8mr25242221wrp.45.1587980407998; Mon, 27 Apr 2020 02:40:07 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id h2sm21659262wro.9.2020.04.27.02.40.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 02:40:07 -0700 (PDT) Date: Mon, 27 Apr 2020 11:40:06 +0200 From: Michal Hocko To: Yafang Shao Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, guro@fb.com, chris@chrisdown.name, linux-mm@kvack.org Subject: Re: [PATCH 3/3] mm: improvements on memcg protection functions Message-ID: <20200427094006.GD28637@dhcp22.suse.cz> References: <20200425152418.28388-1-laoar.shao@gmail.com> <20200425152418.28388-4-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200425152418.28388-4-laoar.shao@gmail.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat 25-04-20 11:24:18, Yafang Shao wrote: > Since proportional memory.{min, low} reclaim is introduced in > commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim"), > it have been proved that the proportional reclaim is hard to understand and > the issues caused by it is harder to understand.[1]. That dilemma faced by > us is caused by that the proportional reclaim mixed up memcg and the > reclaim context. > > In proportional reclaim, the whole reclaim context - includes the memcg > to be reclaimed and the reclaimer, should be considered, rather than > memcg only. > > To make it clear, a new member 'protection' is introduced in the reclaim > context (struct shrink_control) to replace mem_cgroup_protection(). This s@shrink_control@scan_control@ > one is set when we check whether the memcg is protected or not. > > After this change, the issue pointed by me[1] - a really old left-over > value can slow donw target reclaim - can be fixed, and I think it could > also avoid some potential race. The patch would have been much esier to review if you only focused on the effective protection value caching. I really fail to see why you had to make mem_cgroup_protected even more convoluted with more side effects (e.g. sc->memcg_low_skipped). This goes directly opposite to what Johannes was proposing in other email AFAICS. Your changelog doesn't explain why double caching the effective value is an improvement. I believe your goal was to drop the special casing for the reclaim targets which are the only to ignore protection as they are clearly violating the consumption constraints. This makes some sense to me because it makes the special case have a local effect. But I really dislike your patch. Please follow up on Johannes' suggestion to split up the mem_cgroup_protected into parts http://lkml.kernel.org/r/20200424134438.GA496852@cmpxchg.org -- Michal Hocko SUSE Labs