Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752824AbdHVXTd (ORCPT ); Tue, 22 Aug 2017 19:19:33 -0400 Received: from mga07.intel.com ([134.134.136.100]:21587 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751687AbdHVXTb (ORCPT ); Tue, 22 Aug 2017 19:19:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,414,1498546800"; d="scan'208";a="1006619844" From: Andi Kleen To: Christopher Lameter Cc: Kemi Wang , Andrew Morton , Michal Hocko , Mel Gorman , Johannes Weiner , Dave , Jesper Dangaard Brouer , Ying Huang , Aaron Lu , Tim Chen , Linux MM , Linux Kernel Subject: Re: [PATCH 0/2] Separate NUMA statistics from zone statistics References: <1502786736-21585-1-git-send-email-kemi.wang@intel.com> Date: Tue, 22 Aug 2017 16:19:30 -0700 In-Reply-To: (Christopher Lameter's message of "Tue, 22 Aug 2017 16:22:40 -0500 (CDT)") Message-ID: <874lszi41p.fsf@firstfloor.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1825 Lines: 46 Christopher Lameter writes: > Can we simple get rid of the stats or make then configurable (off by > defaut)? I agree they are rarely used and have been rarely used in the past. > > Maybe some instrumentation for perf etc will allow > similar statistics these days? Thus its possible to drop them? > > The space in the pcp pageset is precious and we should strive to use no > more than a cacheline for the diffs. The statistics are useful and we need them sometimes. And more and more runtime switches are a pain -- if you need them they would be likely turned off. The key is just to make them cheap enough that they're not a problem. The only problem was just that that the standard vmstats which are optimized for readers too are too expensive for them. The motivation for the patch was that the frequent atomics were proven to slow the allocator down, and Kemi's patch fixed it and he has shown it with lots of data. I don't really see the point of so much discussion about a single cache line. There are lots of cache lines used all over the VM. Why is this one special? Adding one more shouldn't be that bad. But there's no data at all that touching another cache line here is a problem. It's next to an already touched cache line, so it's highly likely that a prefetcher would catch it anyways. I can see the point of worrying about over all cache line foot print ("death of a thousand cuts") but the right way to address problems like this is use a profiler in a realistic workload and systematically look at the code who actually has cache misses. And I bet we would find quite a few that could be easily avoided and have real payoff. I would really surprise me if it was this cache line. But blocking real demonstrated improvements over a theoretical cache line doesn't really help. -Andi