From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f70.google.com (mail-pg0-f70.google.com [74.125.83.70]) by kanga.kvack.org (Postfix) with ESMTP id 72CA56B0038 for ; Tue, 28 Nov 2017 13:40:54 -0500 (EST) Received: by mail-pg0-f70.google.com with SMTP id a10so394524pgq.3 for ; Tue, 28 Nov 2017 10:40:54 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com. [134.134.136.20]) by mx.google.com with ESMTPS id j33si5735088pld.699.2017.11.28.10.40.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 10:40:53 -0800 (PST) From: Andi Kleen Subject: Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement References: <1511848824-18709-1-git-send-email-kemi.wang@intel.com> <9b4d5612-24eb-4bea-7164-49e42dc76f30@suse.cz> Date: Tue, 28 Nov 2017 10:40:52 -0800 In-Reply-To: <9b4d5612-24eb-4bea-7164-49e42dc76f30@suse.cz> (Vlastimil Babka's message of "Tue, 28 Nov 2017 09:09:11 +0100") Message-ID: <87o9nmjlfv.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Kemi Wang , Greg Kroah-Hartman , Andrew Morton , Michal Hocko , 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 Vlastimil Babka writes: > > I'm worried about the "for_each_possible..." approach here and elsewhere > in the patch as it can be rather excessive compared to the online number > of cpus (we've seen BIOSes report large numbers of possible CPU's). IIRC Even if they report a few hundred extra reading some more shared cache lines is very cheap. The prefetcher usually quickly figures out such a pattern and reads it all in parallel. I doubt it will be noticeable, especially not in a slow path like reading something from proc/sys. > the general approach with vmstat is to query just online cpu's / nodes, > and if they go offline, transfer their accumulated stats to some other > "victim"? That's very complicated, and unlikely to be worth it. -Andi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754049AbdK1Skz (ORCPT ); Tue, 28 Nov 2017 13:40:55 -0500 Received: from mga06.intel.com ([134.134.136.31]:10056 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753979AbdK1Skx (ORCPT ); Tue, 28 Nov 2017 13:40:53 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,468,1505804400"; d="scan'208";a="13014995" From: Andi Kleen To: Vlastimil Babka Cc: Kemi Wang , Greg Kroah-Hartman , Andrew Morton , Michal Hocko , 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 References: <1511848824-18709-1-git-send-email-kemi.wang@intel.com> <9b4d5612-24eb-4bea-7164-49e42dc76f30@suse.cz> Date: Tue, 28 Nov 2017 10:40:52 -0800 In-Reply-To: <9b4d5612-24eb-4bea-7164-49e42dc76f30@suse.cz> (Vlastimil Babka's message of "Tue, 28 Nov 2017 09:09:11 +0100") Message-ID: <87o9nmjlfv.fsf@linux.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vlastimil Babka writes: > > I'm worried about the "for_each_possible..." approach here and elsewhere > in the patch as it can be rather excessive compared to the online number > of cpus (we've seen BIOSes report large numbers of possible CPU's). IIRC Even if they report a few hundred extra reading some more shared cache lines is very cheap. The prefetcher usually quickly figures out such a pattern and reads it all in parallel. I doubt it will be noticeable, especially not in a slow path like reading something from proc/sys. > the general approach with vmstat is to query just online cpu's / nodes, > and if they go offline, transfer their accumulated stats to some other > "victim"? That's very complicated, and unlikely to be worth it. -Andi