From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752591AbcFNPrb (ORCPT ); Tue, 14 Jun 2016 11:47:31 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35235 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342AbcFNPr3 (ORCPT ); Tue, 14 Jun 2016 11:47:29 -0400 Subject: Re: [RFC 03/18] memcontrol: present maximum used memory also for cgroup-v2 To: Michal Hocko References: <1465847065-3577-1-git-send-email-toiwoton@gmail.com> <1465847065-3577-4-git-send-email-toiwoton@gmail.com> <20160614070130.GB5681@dhcp22.suse.cz> Cc: linux-kernel@vger.kernel.org, Johannes Weiner , Vladimir Davydov , Andrew Morton , "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" , "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" From: Topi Miettinen Openpgp: id=A0F2EB0D8452DA908BEC8E911CF9ADDBD610E936 Message-ID: Date: Tue, 14 Jun 2016 15:47:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160614070130.GB5681@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/14/16 07:01, Michal Hocko wrote: > On Mon 13-06-16 22:44:10, Topi Miettinen wrote: >> Present maximum used memory in cgroup memory.current_max. > > It would be really much more preferable to present the usecase in the > patch description. It is true that this information is presented in the > v1 API but the current policy is to export new knobs only when there is > a reasonable usecase for it. > This was stated in the cover letter: https://lkml.org/lkml/2016/6/13/857 "There are many basic ways to control processes, including capabilities, cgroups and resource limits. However, there are far fewer ways to find out useful values for the limits, except blind trial and error. This patch series attempts to fix that by giving at least a nice starting point from the actual maximum values. I looked where each limit is checked and added a call to limit bump nearby." "Cgroups [RFC 02/18] cgroup_pids: track maximum pids [RFC 03/18] memcontrol: present maximum used memory also for [RFC 04/18] device_cgroup: track and present accessed devices For tasks and memory cgroup limits the situation is somewhat better as the current tasks and memory status can be easily seen with ps(1). However, any transient tasks or temporary higher memory use might slip from the view. Device use may be seen with advanced MAC tools, like TOMOYO, but there is no universal method. Program sources typically give no useful indication about memory use or how many tasks there could be." I can add some of this to the commit message, is that sufficient for you? >> Signed-off-by: Topi Miettinen >> --- >> include/linux/page_counter.h | 7 ++++++- >> mm/memcontrol.c | 13 +++++++++++++ >> 2 files changed, 19 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h >> index 7e62920..be4de17 100644 >> --- a/include/linux/page_counter.h >> +++ b/include/linux/page_counter.h >> @@ -9,9 +9,9 @@ struct page_counter { >> atomic_long_t count; >> unsigned long limit; >> struct page_counter *parent; >> + unsigned long watermark; >> >> /* legacy */ >> - unsigned long watermark; >> unsigned long failcnt; >> }; >> >> @@ -34,6 +34,11 @@ static inline unsigned long page_counter_read(struct page_counter *counter) >> return atomic_long_read(&counter->count); >> } >> >> +static inline unsigned long page_counter_read_watermark(struct page_counter *counter) >> +{ >> + return counter->watermark; >> +} >> + >> void page_counter_cancel(struct page_counter *counter, unsigned long nr_pages); >> void page_counter_charge(struct page_counter *counter, unsigned long nr_pages); >> bool page_counter_try_charge(struct page_counter *counter, >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 75e7440..5513771 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -4966,6 +4966,14 @@ static u64 memory_current_read(struct cgroup_subsys_state *css, >> return (u64)page_counter_read(&memcg->memory) * PAGE_SIZE; >> } >> >> +static u64 memory_current_max_read(struct cgroup_subsys_state *css, >> + struct cftype *cft) >> +{ >> + struct mem_cgroup *memcg = mem_cgroup_from_css(css); >> + >> + return (u64)page_counter_read_watermark(&memcg->memory) * PAGE_SIZE; >> +} >> + >> static int memory_low_show(struct seq_file *m, void *v) >> { >> struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m)); >> @@ -5179,6 +5187,11 @@ static struct cftype memory_files[] = { >> .read_u64 = memory_current_read, >> }, >> { >> + .name = "current_max", >> + .flags = CFTYPE_NOT_ON_ROOT, >> + .read_u64 = memory_current_max_read, >> + }, >> + { >> .name = "low", >> .flags = CFTYPE_NOT_ON_ROOT, >> .seq_show = memory_low_show, >> -- >> 2.8.1 >