From: Don Zickus <dzickus@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Joe Mario <jmario@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
eranian@google.com, Arnaldo Carvalho de Melo <acme@kernel.org>,
Andi Kleen <andi@firstfloor.org>,
jolsa@redhat.com, rfowles@redhat.com
Subject: Re: perf: Translating mmap2 ids into socket info?
Date: Wed, 22 Oct 2014 16:38:34 -0400 [thread overview]
Message-ID: <20141022203834.GL135937@redhat.com> (raw)
In-Reply-To: <20141022200219.GM21513@worktop.programming.kicks-ass.net>
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
next prev parent reply other threads:[~2014-10-22 20:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 16:20 perf: Translating mmap2 ids into socket info? Don Zickus
2014-10-22 16:45 ` Peter Zijlstra
2014-10-22 17:42 ` Arnaldo Carvalho de Melo
2014-10-22 18:15 ` Arnaldo Carvalho de Melo
2014-10-22 19:55 ` Peter Zijlstra
2014-10-22 19:54 ` Peter Zijlstra
2014-10-22 18:09 ` Joe Mario
2014-10-22 20:02 ` Peter Zijlstra
2014-10-22 20:38 ` Don Zickus [this message]
2014-10-23 11:01 ` Peter Zijlstra
2014-10-23 11:30 ` Peter Zijlstra
2014-10-23 13:10 ` Don Zickus
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=20141022203834.GL135937@redhat.com \
--to=dzickus@redhat.com \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=jmario@redhat.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rfowles@redhat.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.