lkml.org 
[lkml]   [2014]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2014-10-22 23:01    [W:0.069 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site