Messages in this thread | | | Date | Wed, 22 Oct 2014 16:38:34 -0400 | From | Don Zickus <> | Subject | Re: perf: Translating mmap2 ids into socket info? |
| |
On Wed, Oct 22, 2014 at 10:02:19PM +0200, Peter Zijlstra wrote: > On Wed, Oct 22, 2014 at 02:09:35PM -0400, Joe Mario wrote: > > >Yes, kernel memory is directly addresses, you basically have a static > > >address->node mapping, it never changes. > > > > For kernel addresses, is there a reason not to have it available in perf, > > especially when that knowledge is important to understanding a numa-related slowdown? > > Dunno why that isn't exposed in sysfs. > > > In our case, when we booted with one configuration, AIM ran fine. When we > > booted another way, AIM's performance dropped 50%. It was all due to the dentry > > lock being located on a different (now remote) numa node. > > > > We used your dmesg approach to track down the home node in an attempt to understand > > what was different between the two boots. But the problem would have been obvious > > if perf simply listed the home node info. > > Or if you'd used more counters that track the node interconnect traffic > ;-) There are a few simple ones that count local/remote type things > (offcore), but using the uncore counters you can track way more.
Ha! I have been telling myself for a year I would try to learn more about those offcore/uncore counters. Is there documentation for how to access the uncore stuff? Do I have to long hand it with 'perf record -e uncore_qpi_1/<stuff>/ foo'?
Cheers, Don
| |