Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752916AbdHWBPs (ORCPT ); Tue, 22 Aug 2017 21:15:48 -0400 Received: from mga14.intel.com ([192.55.52.115]:20326 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752619AbdHWBPr (ORCPT ); Tue, 22 Aug 2017 21:15:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,415,1498546800"; d="scan'208";a="140940799" From: kemi Subject: Re: [PATCH 0/2] Separate NUMA statistics from zone statistics To: Christopher Lameter Cc: Andrew Morton , Michal Hocko , Mel Gorman , Johannes Weiner , Dave , Andi Kleen , Jesper Dangaard Brouer , Ying Huang , Aaron Lu , Tim Chen , Linux MM , Linux Kernel References: <1502786736-21585-1-git-send-email-kemi.wang@intel.com> Message-ID: <403c809c-cd37-db66-5f33-3ea6b6bee52d@intel.com> Date: Wed, 23 Aug 2017 09:14:17 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2539 Lines: 65 On 2017年08月23日 05:22, Christopher Lameter wrote: > 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. > I agree that we can make numa stats as well as other stats items that are rarely used configurable. Perhaps we can introduce a general mechanism to hide such unimportant stats(suggested by *Dave Hansen* initially), it works like this: 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 What's your idea for that? I can help to implement it later. But it may not a good idea to simply get rid of such kinds of stats. > 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. > > Andi has helped to explain it very clearly. Thanks very much. For 64-bit OS: base with this patch(even include numa_threshold) sizeof(struct per_cpu_pageset) 88 96 Copy the discussion before from another email thread in case you missed it: > Hi Mel > I am refreshing this patch. Would you pls be more explicit of what "that > structure" indicates. > If you mean "struct per_cpu_pageset", for 64 bits machine, this structure > still occupies two caches line after extending s8 to s16/u16, that should > not be a problem. You're right, I was in error. I miscalculated badly initially. It still fits in as expected. > For 32 bits machine, we probably does not need to extend > the size of vm_numa_stat_diff[] since 32 bits OS nearly not be used in large > numa system, and s8/u8 is large enough for it, in this case, we can keep the > same size of "struct per_cpu_pageset". > I don't believe it's worth the complexity of making this bitness-specific. 32-bit takes penalties in other places and besides, 32-bit does not necessarily mean a change in cache line size. Fortunately, I think you should still be able to gain a bit more with some special casing the fact it's always incrementing and always do full spill of the counters instead of half. If so, then using u16 instead of s16 should also reduce the update frequency. However, if you find it's too complex and the gain is too marginal then I'll ack without it.