From: Andi Kleen <ak@linux.intel.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Kemi Wang <kemi.wang@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Mel Gorman <mgorman@techsingularity.net>,
Johannes Weiner <hannes@cmpxchg.org>,
Christopher Lameter <cl@linux.com>,
YASUAKI ISHIMATSU <yasu.isimatu@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Nikolay Borisov <nborisov@suse.com>,
Pavel Tatashin <pasha.tatashin@oracle.com>,
David Rientjes <rientjes@google.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Dave <dave.hansen@linux.intel.com>,
Andi Kleen <andi.kleen@intel.com>,
Tim Chen <tim.c.chen@intel.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Ying Huang <ying.huang@intel.com>, Aaron Lu <aaron.lu@intel.com>,
Aubrey Li <aubrey.li@intel.com>, Linux MM <linux-mm@kvack.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement
Date: Tue, 28 Nov 2017 10:40:52 -0800 [thread overview]
Message-ID: <87o9nmjlfv.fsf@linux.intel.com> (raw)
In-Reply-To: <9b4d5612-24eb-4bea-7164-49e42dc76f30@suse.cz> (Vlastimil Babka's message of "Tue, 28 Nov 2017 09:09:11 +0100")
Vlastimil Babka <vbabka@suse.cz> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@linux.intel.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Kemi Wang <kemi.wang@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Mel Gorman <mgorman@techsingularity.net>,
Johannes Weiner <hannes@cmpxchg.org>,
Christopher Lameter <cl@linux.com>,
YASUAKI ISHIMATSU <yasu.isimatu@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Nikolay Borisov <nborisov@suse.com>,
Pavel Tatashin <pasha.tatashin@oracle.com>,
David Rientjes <rientjes@google.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Dave <dave.hansen@linux.intel.com>,
Andi Kleen <andi.kleen@intel.com>,
Tim Chen <tim.c.chen@intel.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Ying Huang <ying.huang@intel.com>, Aaron Lu <aaron.lu@intel.com>,
Aubrey Li <aubrey.li@intel.com>, Linux MM <linux-mm@kvack.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement
Date: Tue, 28 Nov 2017 10:40:52 -0800 [thread overview]
Message-ID: <87o9nmjlfv.fsf@linux.intel.com> (raw)
In-Reply-To: <9b4d5612-24eb-4bea-7164-49e42dc76f30@suse.cz> (Vlastimil Babka's message of "Tue, 28 Nov 2017 09:09:11 +0100")
Vlastimil Babka <vbabka@suse.cz> 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
next prev parent reply other threads:[~2017-11-28 18:40 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 6:00 [PATCH 1/2] mm: NUMA stats code cleanup and enhancement Kemi Wang
2017-11-28 6:00 ` Kemi Wang
2017-11-28 6:00 ` [PATCH 2/2] mm: Rename zone_statistics() to numa_statistics() Kemi Wang
2017-11-28 6:00 ` Kemi Wang
2017-11-28 8:09 ` [PATCH 1/2] mm: NUMA stats code cleanup and enhancement Vlastimil Babka
2017-11-28 8:09 ` Vlastimil Babka
2017-11-28 8:33 ` kemi
2017-11-28 8:33 ` kemi
2017-11-28 18:40 ` Andi Kleen [this message]
2017-11-28 18:40 ` Andi Kleen
2017-11-28 21:56 ` Andrew Morton
2017-11-28 21:56 ` Andrew Morton
2017-11-28 22:52 ` Vlastimil Babka
2017-11-28 22:52 ` Vlastimil Babka
2017-11-29 12:17 ` Michal Hocko
2017-11-29 12:17 ` Michal Hocko
2017-11-30 5:56 ` kemi
2017-11-30 5:56 ` kemi
2017-11-30 8:53 ` Michal Hocko
2017-11-30 8:53 ` Michal Hocko
2017-11-30 9:32 ` kemi
2017-11-30 9:32 ` kemi
2017-11-30 9:45 ` Michal Hocko
2017-11-30 9:45 ` Michal Hocko
2017-11-30 11:06 ` Wang, Kemi
2017-11-30 11:06 ` Wang, Kemi
2017-12-08 8:38 ` kemi
2017-12-08 8:38 ` kemi
2017-12-08 8:47 ` Michal Hocko
2017-12-08 8:47 ` Michal Hocko
2017-12-12 2:05 ` kemi
2017-12-12 2:05 ` kemi
2017-12-12 8:11 ` Michal Hocko
2017-12-12 8:11 ` Michal Hocko
2017-12-14 1:40 ` kemi
2017-12-14 1:40 ` kemi
2017-12-14 7:29 ` Michal Hocko
2017-12-14 7:29 ` Michal Hocko
2017-12-14 8:55 ` kemi
2017-12-14 8:55 ` kemi
2017-12-14 9:23 ` Michal Hocko
2017-12-14 9:23 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o9nmjlfv.fsf@linux.intel.com \
--to=ak@linux.intel.com \
--cc=aaron.lu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=aryabinin@virtuozzo.com \
--cc=aubrey.li@intel.com \
--cc=bigeasy@linutronix.de \
--cc=brouer@redhat.com \
--cc=cl@linux.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=kemi.wang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=nborisov@suse.com \
--cc=pasha.tatashin@oracle.com \
--cc=rientjes@google.com \
--cc=tim.c.chen@intel.com \
--cc=vbabka@suse.cz \
--cc=yasu.isimatu@gmail.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.