Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564AbdLHIsB (ORCPT ); Fri, 8 Dec 2017 03:48:01 -0500 Received: from mx2.suse.de ([195.135.220.15]:38663 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750944AbdLHIr7 (ORCPT ); Fri, 8 Dec 2017 03:47:59 -0500 Date: Fri, 8 Dec 2017 09:47:55 +0100 From: Michal Hocko To: kemi Cc: Greg Kroah-Hartman , Andrew Morton , Vlastimil Babka , Mel Gorman , Johannes Weiner , Christopher Lameter , YASUAKI ISHIMATSU , Andrey Ryabinin , Nikolay Borisov , Pavel Tatashin , David Rientjes , Sebastian Andrzej Siewior , Dave , Andi Kleen , Tim Chen , Jesper Dangaard Brouer , Ying Huang , Aaron Lu , Aubrey Li , Linux MM , Linux Kernel Subject: Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement Message-ID: <20171208084755.GS20234@dhcp22.suse.cz> References: <1511848824-18709-1-git-send-email-kemi.wang@intel.com> <20171129121740.f6drkbktc43l5ib6@dhcp22.suse.cz> <4b840074-cb5f-3c10-d65b-916bc02fb1ee@intel.com> <20171130085322.tyys6xbzzvui7ogz@dhcp22.suse.cz> <0f039a89-5500-1bf5-c013-d39ba3bf62bd@intel.com> <20171130094523.vvcljyfqjpbloe5e@dhcp22.suse.cz> <9cd6cc9f-252a-3c6f-2f1f-e39d4ec0457b@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9cd6cc9f-252a-3c6f-2f1f-e39d4ec0457b@intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 782 Lines: 25 On Fri 08-12-17 16:38:46, kemi wrote: > > > On 2017年11月30日 17:45, Michal Hocko wrote: > > On Thu 30-11-17 17:32:08, kemi wrote: > > > Do not get me wrong. If we want to make per-node stats more optimal, > > then by all means let's do that. But having 3 sets of counters is just > > way to much. > > > > Hi, Michal > Apologize to respond later in this email thread. > > After thinking about how to optimize our per-node stats more gracefully, > we may add u64 vm_numa_stat_diff[] in struct per_cpu_nodestat, thus, > we can keep everything in per cpu counter and sum them up when read /proc > or /sys for numa stats. > What's your idea for that? thanks I would like to see a strong argument why we cannot make it a _standard_ node counter. -- Michal Hocko SUSE Labs