Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752008AbdLSQUm (ORCPT ); Tue, 19 Dec 2017 11:20:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:58342 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbdLSQUf (ORCPT ); Tue, 19 Dec 2017 11:20:35 -0500 Date: Tue, 19 Dec 2017 17:20:29 +0100 From: Michal Hocko To: Christopher Lameter Cc: Kemi Wang , Greg Kroah-Hartman , Andrew Morton , Vlastimil Babka , Mel Gorman , Johannes Weiner , 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 v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16 Message-ID: <20171219162029.GD2787@dhcp22.suse.cz> References: <1513665566-4465-1-git-send-email-kemi.wang@intel.com> <1513665566-4465-3-git-send-email-kemi.wang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 1309 Lines: 26 On Tue 19-12-17 10:05:48, Cristopher Lameter wrote: > On Tue, 19 Dec 2017, Kemi Wang wrote: > > > The type s8 used for vm_diff_nodestat[] as local cpu counters has the > > limitation of global counters update frequency, especially for those > > monotone increasing type of counters like NUMA counters with more and more > > cpus/nodes. This patch extends the type of vm_diff_nodestat from s8 to s16 > > without any functionality change. > > Well the reason for s8 was to keep the data structures small so that they > fit in the higher level cpu caches. The large these structures become the > more cachelines are used by the counters and the larger the performance > influence on the code that should not be impacted by the overhead. I am not sure I understand. We usually do not access more counters in the single code path (well, PGALLOC and NUMA counteres is more of an exception). So it is rarely an advantage that the whole array is in the same cache line. Besides that this is allocated by the percpu allocator aligns to the type size rather than cache lines AFAICS. Maybe it used to be all different back then when the code has been added but arguing about cache lines seems to be a bit problematic here. Maybe you have some specific workloads which can prove me wrong? -- Michal Hocko SUSE Labs