Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751517AbdLNI55 (ORCPT ); Thu, 14 Dec 2017 03:57:57 -0500 Received: from mga01.intel.com ([192.55.52.88]:24688 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbdLNI5z (ORCPT ); Thu, 14 Dec 2017 03:57:55 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,399,1508828400"; d="scan'208";a="2442328" From: kemi Subject: Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement To: Michal Hocko 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 References: <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> <20171208084755.GS20234@dhcp22.suse.cz> <20171212081126.GK4779@dhcp22.suse.cz> <20171214072927.GB16951@dhcp22.suse.cz> Message-ID: <2176cf74-210a-01fe-3a7e-272a69b7bdc6@intel.com> Date: Thu, 14 Dec 2017 16:55:54 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171214072927.GB16951@dhcp22.suse.cz> 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: 1692 Lines: 41 On 2017年12月14日 15:29, Michal Hocko wrote: > On Thu 14-12-17 09:40:32, kemi wrote: >> >> >> or sometimes >> NUMA stats can't be disabled in their environments. > > why? > >> That's the reason >> why we spent time to do that optimization other than simply adding a runtime >> configuration interface. >> >> Furthermore, the code we optimized for is the core area of kernel that can >> benefit most of kernel actions, more or less I think. >> >> All right, let's think about it in another way, does a u64 percpu array per-node >> for NUMA stats really make code too much complicated and hard to maintain? >> I'm afraid not IMHO. > > I disagree. The whole numa stat things has turned out to be nasty to > maintain. For a very limited gain. Now you are just shifting that > elsewhere. Look, there are other counters taken in the allocator, we do > not want to treat them specially. We have a nice per-cpu infrastructure > here so I really fail to see why we should code-around it. If that can > be improved then by all means let's do it. > Yes, I agree with you that we may improve current per-cpu infrastructure. May we have a chance to increase the size of vm_node_stat_diff from s8 to s16 for this "per-cpu infrastructure" (s32 in per-cpu counter infrastructure)? The limitation of type s8 seems not enough with more and more cpu cores, especially for those monotone increasing type of counters like NUMA counters. before after(moving numa to per_cpu_nodestat and change s8 to s16) sizeof(struct per_cpu_nodestat) 28 68 If ok, we can also keep that improvement in a nice way.