From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932133AbcFNOZa (ORCPT ); Tue, 14 Jun 2016 10:25:30 -0400 Received: from outbound-smtp05.blacknight.com ([81.17.249.38]:55121 "EHLO outbound-smtp05.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932109AbcFNOZ0 (ORCPT ); Tue, 14 Jun 2016 10:25:26 -0400 Date: Tue, 14 Jun 2016 15:25:07 +0100 From: Mel Gorman To: Christoph Lameter Cc: Andrew Morton , Linux-MM , Rik van Riel , Vlastimil Babka , Johannes Weiner , LKML Subject: Re: [PATCH 01/27] mm, vmstat: Add infrastructure for per-node vmstats Message-ID: <20160614142506.GA1868@techsingularity.net> References: <1465495483-11855-1-git-send-email-mgorman@techsingularity.net> <1465495483-11855-2-git-send-email-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 13, 2016 at 12:26:13PM -0500, Christoph Lameter wrote: > On Thu, 9 Jun 2016, Mel Gorman wrote: > > > VM statistic counters for reclaim decisions are zone-based. If the kernel > > is to reclaim on a per-node basis then we need to track per-node statistics > > but there is no infrastructure for that. The most notable change is that > > There is node_page_state() so the value of any counter per node is already > available. Note that some of the counters (NUMA_xx) for example do not > make much sense as per zone counters and are effectively used as per node > counters. > > So the main effect you are looking for is to have the counters stored in > the per node structure as opposed to the per zone struct in order to > avoid the summing? Yes. > Doing so duplicates a large amount of code it seems. > Also yes. I considered macro magic to cover it but it turned into a major mess. They could always be summed so it would be a minor performance dent and a heavier cache footprint. > If you do this then also move over certain counters that have more of a > per node use from per zone to per node. Like the NUMA_xxx counters. > As the NUMA counters are consumed by userspace, I worried that it would break some tools. If the rest of the series gets solidified then I will do it as a single patch on top so it can be reverted if necessary relatively easily. -- Mel Gorman SUSE Labs