Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3827634pxk; Tue, 8 Sep 2020 03:43:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCNuMx6FaRvI2dslJMASJzPKnj0T6v1q3uUl1j306MmxGy8IXXiFlVsB8WJ7TDyNJ1Y7o2 X-Received: by 2002:a17:906:8559:: with SMTP id h25mr24723027ejy.536.1599561781950; Tue, 08 Sep 2020 03:43:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599561781; cv=none; d=google.com; s=arc-20160816; b=BSKSixX5t9XyVMdUtz8s7LCEhulJPDveD4ThmUgHOzWrItNtIfdegRNxcuxoAFMxR+ J4tuWoeoX08FLn7pCbtxNK32/UDCwfQj209gbBUgpvw+dBl7APXUKM5e5fX3Y24XZW/4 N0hi6RPJHGCWYoPG99ybcWIMDI27IfkgIVW/KpdlJNV5F6tsNXnN7khGBQrlIGU2E0Vh IC2xI+57aVIiXS+f28okUf8e3h01lBzeeDVKfG6IT5rC8Lq7sP97w+UILtKdqcqdUDwL W1WMq5sDlgFp1gwBAvywQyPcgw6ZVibhFMxe6XRkS23ed+ekYcGdTGGWft72wLB25H7h ++kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=f01IUnGRu8doQzVgXfbLZHPVbjTrRJBOA7pTfQF7l7k=; b=nVkZfHR8s5ylnM7yvsAXpnei22YbBHfwffwMfUM943NQHv+mvD02/pMfhDWdO8asUj YIJtc+fgJJYNA089a/YrLXsw9OnPtvd48gN9lZ0HUzmn9EvSepztwYJd0g009oZje8D9 yTFq8HmzMhx2PSdPjVIpGOlkhkpFl8lZLGngCKMDRufo04fdp7MZG37t1Zbp2NbOuBdn wOl918cySiGSL0CfYiPg/uZ0xBM93B6SzGnadBQ1CwCFRsyFAMQzep/L39cZVST7YiEW rC9hlTTZPvNKbdzER5tDh7J7AQ1XNy47TZ3J0wtbvrWLRmnJLhrODZjwjmlqllDtn2gb uTSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y12si10903867edv.98.2020.09.08.03.42.40; Tue, 08 Sep 2020 03:43:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729095AbgIHKjt (ORCPT + 99 others); Tue, 8 Sep 2020 06:39:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:37308 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729775AbgIHKir (ORCPT ); Tue, 8 Sep 2020 06:38:47 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CB8FDAF3F; Tue, 8 Sep 2020 10:38:16 +0000 (UTC) Date: Tue, 8 Sep 2020 12:38:15 +0200 From: Michal Hocko To: Alex Shi Cc: Andrew Morton , Johannes Weiner , Vladimir Davydov , linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org Subject: Re: [PATCH] mm/memcg: rename watermark as max_usage Message-ID: <20200908103815.GC26850@dhcp22.suse.cz> References: <1599560721-68915-1-git-send-email-alex.shi@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1599560721-68915-1-git-send-email-alex.shi@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 08-09-20 18:25:21, Alex Shi wrote: > The page_counter's watermark used to show as max_usage_in_bytes in memory > cgroup. named as watermark is a kind of misleadking. So, let's rename it > as it usage. Is this really necessary? This just adds a code churn for something that is highly subjective. > Signed-off-by: Alex Shi > Cc: Andrew Morton > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: linux-kernel@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: cgroups@vger.kernel.org > --- > include/linux/page_counter.h | 6 +++--- > mm/hugetlb_cgroup.c | 8 ++++---- > mm/memcontrol.c | 4 ++-- > mm/page_counter.c | 12 ++++++------ > 4 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h > index 85bd413e784e..813f2da26c36 100644 > --- a/include/linux/page_counter.h > +++ b/include/linux/page_counter.h > @@ -25,7 +25,7 @@ struct page_counter { > atomic_long_t children_low_usage; > > /* legacy */ > - unsigned long watermark; > + unsigned long max_usage; /* max_usage_in_bytes */ > unsigned long failcnt; > }; > > @@ -67,9 +67,9 @@ static inline void page_counter_set_high(struct page_counter *counter, > int page_counter_memparse(const char *buf, const char *max, > unsigned long *nr_pages); > > -static inline void page_counter_reset_watermark(struct page_counter *counter) > +static inline void page_counter_reset_max_usage(struct page_counter *counter) > { > - counter->watermark = page_counter_read(counter); > + counter->max_usage = page_counter_read(counter); > } > > #endif /* _LINUX_PAGE_COUNTER_H */ > diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c > index 1f87aec9ab5c..c7484f5eb8ef 100644 > --- a/mm/hugetlb_cgroup.c > +++ b/mm/hugetlb_cgroup.c > @@ -437,9 +437,9 @@ static u64 hugetlb_cgroup_read_u64(struct cgroup_subsys_state *css, > case RES_RSVD_LIMIT: > return (u64)rsvd_counter->max * PAGE_SIZE; > case RES_MAX_USAGE: > - return (u64)counter->watermark * PAGE_SIZE; > + return (u64)counter->max_usage * PAGE_SIZE; > case RES_RSVD_MAX_USAGE: > - return (u64)rsvd_counter->watermark * PAGE_SIZE; > + return (u64)rsvd_counter->max_usage * PAGE_SIZE; > case RES_FAILCNT: > return counter->failcnt; > case RES_RSVD_FAILCNT: > @@ -553,10 +553,10 @@ static ssize_t hugetlb_cgroup_reset(struct kernfs_open_file *of, > > switch (MEMFILE_ATTR(of_cft(of)->private)) { > case RES_MAX_USAGE: > - page_counter_reset_watermark(counter); > + page_counter_reset_max_usage(counter); > break; > case RES_RSVD_MAX_USAGE: > - page_counter_reset_watermark(rsvd_counter); > + page_counter_reset_max_usage(rsvd_counter); > break; > case RES_FAILCNT: > counter->failcnt = 0; > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 8c74f1200261..21b73de53073 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -3559,7 +3559,7 @@ static u64 mem_cgroup_read_u64(struct cgroup_subsys_state *css, > case RES_LIMIT: > return (u64)counter->max * PAGE_SIZE; > case RES_MAX_USAGE: > - return (u64)counter->watermark * PAGE_SIZE; > + return (u64)counter->max_usage * PAGE_SIZE; > case RES_FAILCNT: > return counter->failcnt; > case RES_SOFT_LIMIT: > @@ -3839,7 +3839,7 @@ static ssize_t mem_cgroup_reset(struct kernfs_open_file *of, char *buf, > > switch (MEMFILE_ATTR(of_cft(of)->private)) { > case RES_MAX_USAGE: > - page_counter_reset_watermark(counter); > + page_counter_reset_max_usage(counter); > break; > case RES_FAILCNT: > counter->failcnt = 0; > diff --git a/mm/page_counter.c b/mm/page_counter.c > index afe22ad335cc..d88ee074f4a6 100644 > --- a/mm/page_counter.c > +++ b/mm/page_counter.c > @@ -75,10 +75,10 @@ void page_counter_charge(struct page_counter *counter, unsigned long nr_pages) > propagate_protected_usage(c, new); > /* > * This is indeed racy, but we can live with some > - * inaccuracy in the watermark. > + * inaccuracy in the max_usage. > */ > - if (new > READ_ONCE(c->watermark)) > - WRITE_ONCE(c->watermark, new); > + if (new > READ_ONCE(c->max_usage)) > + WRITE_ONCE(c->max_usage, new); > } > } > > @@ -129,10 +129,10 @@ bool page_counter_try_charge(struct page_counter *counter, > propagate_protected_usage(c, new); > /* > * Just like with failcnt, we can live with some > - * inaccuracy in the watermark. > + * inaccuracy in the max_usage. > */ > - if (new > READ_ONCE(c->watermark)) > - WRITE_ONCE(c->watermark, new); > + if (new > READ_ONCE(c->max_usage)) > + WRITE_ONCE(c->max_usage, new); > } > return true; > > -- > 1.8.3.1 -- Michal Hocko SUSE Labs