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 F072DC54FD0 for ; Mon, 27 Apr 2020 10:50:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9DE5620661 for ; Mon, 27 Apr 2020 10:50:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DE5620661 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 024218E0005; Mon, 27 Apr 2020 06:50:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F162A8E0001; Mon, 27 Apr 2020 06:50:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDD938E0005; Mon, 27 Apr 2020 06:50:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id C5C6A8E0001 for ; Mon, 27 Apr 2020 06:50:26 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8E1A93A82 for ; Mon, 27 Apr 2020 10:50:26 +0000 (UTC) X-FDA: 76753316052.10.hall26_5b20a37199001 X-HE-Tag: hall26_5b20a37199001 X-Filterd-Recvd-Size: 5173 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Apr 2020 10:50:26 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id j1so19987519wrt.1 for ; Mon, 27 Apr 2020 03:50:25 -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=7dzcAB0lda9wkf8MhxZTh3obPC82fZdNY2KA4FipdPg=; b=FwxxMMZnJ1GLvrSu9u39Hy36D1nSKm822sNhajcnLpu7OGtCEgia0MYmpiriduHPKh 4hDeUh47q0K8PZpdoG2hcXu4cAUxH6NbEVOt4DnoL6bkvokidOi44HmB8oKQAdE6n8Uk OM3WQQ+GU/8605ey4vsyva+nJyTVpa1wd3ea7YqA9hQIltND37YW3pjQI7PTvbJVm+0b WUBgPtFr3cGbQYqFlELxwBwKUrV4VMkTl3//gRkeWSlwTCI9jnnaxMrhutCHsI7+s+1S Ii4GQdNuDqmnIywi4MLjqgSLn2lBMUt2teYWkqU1JDhERmJbSAXxVYBP80MNsY9eELVF 0AAA== X-Gm-Message-State: AGi0PuahoGrlxf57fDsghyktdDPyVq1YnA4f+CiGkLc+q09xzifA39lA G0fNTx49zLUXkY0VInHlg58= X-Google-Smtp-Source: APiQypKxQgUVovtV4pYmo72MKBF8Nq7Y1jzM4qqEmyW+DSA5Z7Xa0FkGTUTnpb1A6alWzjOkGOcvPw== X-Received: by 2002:adf:f2ce:: with SMTP id d14mr13479206wrp.145.1587984624997; Mon, 27 Apr 2020 03:50:24 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id c83sm16584664wmd.23.2020.04.27.03.50.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 03:50:24 -0700 (PDT) Date: Mon, 27 Apr 2020 12:50:22 +0200 From: Michal Hocko To: Yafang Shao Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Chris Down , Linux MM Subject: Re: [PATCH 3/3] mm: improvements on memcg protection functions Message-ID: <20200427105022.GE28637@dhcp22.suse.cz> References: <20200425152418.28388-1-laoar.shao@gmail.com> <20200425152418.28388-4-laoar.shao@gmail.com> <20200427094006.GD28637@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 27-04-20 18:09:27, Yafang Shao wrote: > On Mon, Apr 27, 2020 at 5:40 PM Michal Hocko wrote: > > > > 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@ > > > > Thanks for pointing this out. > > > > 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. > > > > Sorry, I failed to see what the advantage of Johannes's proposal > except the better naming. The immediate advantage is that predicate should better not have any side effect. So splitting into the calculation part which has clearly defined side effects and having a simple predicate that consults pre-calculated values makes a lot of sense to me. > > Your changelog doesn't explain why double caching the effective value is > > an improvement. > > The improvement is, to avoid getting an wrong value calculated by > other reclaimers and avoid issues in mem_cgroup_protection() that we > haven't noticed. This is not true in general. There is still parallel calculation done and so parallel reclaimers might affect each other. Your patch only makes a real difference for leaf memcgs which are the reclaim target as well. All intermediate nodes really do not care about the cached values because they do not have any pages on the LRU lists. -- Michal Hocko SUSE Labs