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;
IronPort-SDR: WV0zH0s8XSv8BRdyEGxIDsROb4Ce0WdPVLsYjxIA2Vs7lP9WnJJcsAgRXJrk8h+2QQcvgjFjhW
 YqY8fwoDVapw==
IronPort-SDR: XXUouqSJAn1VhHZCiNgfISHb83SMuN06jgxmcHhs3xupN+cDr+gpJegoaUAfhAJZO4c5N3xx7I
 r3jZCOk7K+Vg==
Date:   Wed, 3 Jun 2020 07:28:53 -0700
From:   Andi Kleen <andi.kleen@intel.com>
To:     Feng Tang <feng.tang@intel.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Michal Hocko <mhocko@suse.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Matthew Wilcox <willy@infradead.org>,
        Mel Gorman <mgorman@suse.de>,
        Kees Cook <keescook@chromium.org>, Qian Cai <cai@lca.pw>,
        tim.c.chen@intel.com, dave.hansen@intel.com, ying.huang@intel.com,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/4] mm/util.c: make vm_memory_committed() more
 accurate
Message-ID: <20200603142853.GE621576@tassilo.jf.intel.com>
References: <1590714370-67182-1-git-send-email-feng.tang@intel.com>
 <1590714370-67182-3-git-send-email-feng.tang@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1590714370-67182-3-git-send-email-feng.tang@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> Its time cost is about 800 nanoseconds on a 2C/4T platform and
> 2~3 microseconds on a 2S/36C/72T server in normal case, and in
> worst case where vm_committed_as's spinlock is under severe
> contention, it costs 30~40 microseconds for the 2S/36C/72T sever,

This will be likely 40-80us on larger systems, although the overhead
is often non linear so it might get worse.

> which should be fine for its only two users: /proc/meminfo and
> HyperV balloon driver's status trace per second.

There are some setups who do frequent sampling of /proc/meminfo
in the background.  Increased overhead could be a problem for them.
But not proposing a change now. If someone complains have to 
revisit I guess, perhaps adding a rate limit of some sort.

-Andi