[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170918055023.ikvocc5q4i4rmq2p@dhcp22.suse.cz>
Date: Mon, 18 Sep 2017 07:50:23 +0200
From: Michal Hocko <mhocko@...nel.org>
To: kemi <kemi.wang@...el.com>
Cc: "Luis R . Rodriguez" <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>,
Mel Gorman <mgorman@...hsingularity.net>,
Johannes Weiner <hannes@...xchg.org>,
Christopher Lameter <cl@...ux.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Vlastimil Babka <vbabka@...e.cz>,
Dave <dave.hansen@...ux.intel.com>,
Tim Chen <tim.c.chen@...el.com>,
Andi Kleen <andi.kleen@...el.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Ying Huang <ying.huang@...el.com>,
Aaron Lu <aaron.lu@...el.com>,
Proc sysctl <linux-fsdevel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] mm, sysctl: make VM stats configurable
On Mon 18-09-17 11:22:37, kemi wrote:
>
>
> On 2017年09月15日 19:49, Michal Hocko wrote:
> > On Fri 15-09-17 17:23:24, Kemi Wang wrote:
> >> This patch adds a tunable interface that allows VM stats configurable, as
> >> suggested by Dave Hansen and Ying Huang.
> >>
> >> When performance becomes a bottleneck and you can tolerate some possible
> >> tool breakage and some decreased counter precision (e.g. numa counter), you
> >> can do:
> >> echo [C|c]oarse > /proc/sys/vm/vmstat_mode
> >>
> >> When performance is not a bottleneck and you want all tooling to work, you
> >> can do:
> >> echo [S|s]trict > /proc/sys/vm/vmstat_mode
> >>
> >> We recommend automatic detection of virtual memory statistics by system,
> >> this is also system default configuration, you can do:
> >> echo [A|a]uto > /proc/sys/vm/vmstat_mode
> >>
> >> The next patch handles numa statistics distinctively based-on different VM
> >> stats mode.
> >
> > I would just merge this with the second patch so that it is clear how
> > those modes are implemented. I am also wondering why cannot we have a
> > much simpler interface and implementation to enable/disable numa stats
> > (btw. sysctl_vm_numa_stats would be more descriptive IMHO).
> >
>
> Apologize for resending it, because I found my previous reply mixed with
> Michal's in many email client.
>
> The motivation is that we propose a general tunable interface for VM stats.
> This would be more scalable, since we don't have to add an individual
> Interface for each type of counter that can be configurable.
Can you envision which other counters would fall into the same category?
> In the second patch, NUMA stats, as an example, can benefit for that.
> If you still hold your idea, I don't mind to merge them together.
Well, I would prefer simplicy in the first place.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists