linux-kernel - Re: [PATCH 0/2] Separate NUMA statistics from zone statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6a72ed71-8096-9a61-e783-d750cdcaea01@linux.intel.com>
Date:   Tue, 22 Aug 2017 21:55:41 -0700
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     kemi <kemi.wang@...el.com>, Christopher Lameter <cl@...ux.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Johannes Weiner <hannes@...xchg.org>,
        Andi Kleen <andi.kleen@...el.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Ying Huang <ying.huang@...el.com>,
        Aaron Lu <aaron.lu@...el.com>, Tim Chen <tim.c.chen@...el.com>,
        Linux MM <linux-mm@...ck.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Separate NUMA statistics from zone statistics

On 08/22/2017 06:14 PM, kemi wrote:
> when performance is not important and when you want all tooling to work, you set:
> 
> 	sysctl vm.strict_stats=1
> 
> but if you can tolerate some possible tool breakage and some decreased
> counter precision, you can do:
> 
> 	sysctl vm.strict_stats=0

My other thought was to try to set vm.strict_stats=0 and move to
vm.strict_stats=1 (and issue a printk) when somebody reads
/proc/zoneinfo (or the other files where the expensive stats are displayed).

We'd need three modes for the expensive stats:

	1. Off by default
	2. On.  (#1 transforms to this by default when stats are read)
	3. Off permanently.  An *actual* tunable that someone could set
	   on systems that want to be able to read the stat files, don't
	   care about precision, and want the best performance.

That way, virtually everybody (who falls into mode #1 or #2) gets what
they want.  The only folks who have to mess with a tunable are the
really weird, picky ones who use option #3.