From: Don Zickus <dzickus@redhat.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@ghostprotocols.net, peterz@infradead.org,
LKML <linux-kernel@vger.kernel.org>,
namhyung@gmail.com, eranian@google.com,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH 6/6] perf: Add dcacheline sort
Date: Mon, 19 May 2014 10:18:37 -0400 [thread overview]
Message-ID: <20140519141837.GI50500@redhat.com> (raw)
In-Reply-To: <20140519133414.GD20810@krava.brq.redhat.com>
On Mon, May 19, 2014 at 03:34:14PM +0200, Jiri Olsa wrote:
> On Fri, May 16, 2014 at 10:30:02AM -0400, Don Zickus wrote:
> > On Fri, May 16, 2014 at 04:05:51PM +0200, Jiri Olsa wrote:
> > > On Fri, May 16, 2014 at 09:30:58AM -0400, Don Zickus wrote:
> > > > On Fri, May 16, 2014 at 01:47:57PM +0200, Jiri Olsa wrote:
> > > > > On Tue, May 13, 2014 at 12:48:17PM -0400, Don Zickus wrote:
> > > > > > In perf's 'mem-mode', one can get access to a whole bunch of details specific to a
> > > > > > particular sample instruction. A bunch of those details relate to the data
> > > > > > address.
> > > > > >
> > > > > > One interesting thing you can do with data addresses is to convert them into a unique
> > > > > > cacheline they belong too. Organizing these data cachelines into similar groups and sorting
> > > > > > them can reveal cache contention.
> > > > > >
> > > > > > This patch creates an alogorithm based on various sample details that can help group
> > > > > > entries together into data cachelines and allows 'perf report' to sort on it.
> > > > > >
> > > > > > The algorithm relies on having proper mmap2 support in the kernel to help determine
> > > > > > if the memory map the data address belongs to is private to a pid or globally shared.
> > > > > >
> > > > > > The alogortithm is as follows:
> > > > > >
> > > > > > o group cpumodes together
> > > > > > o group entries with discovered maps together
> > > > > > o sort on major, minor, inode and inode generation numbers
> > > > > > o if userspace anon, then sort on pid
> > > > > > o sort on cachelines based on data addresses
> > > > >
> > > > > needs some collumn width refresh or something..? ;-)
> > > >
> > > > Not sure what you mean here.
> > > >
> > > > >
> > > > > # Overhead Data Cacheline
> > > > > # ........ .......................
> > >
> > > header not being wide enough to cover the longest data
> >
> > Ah. Ok. So I am not sure the right way to fix that. As the current
> > header seems to be hardcoded with a bunch of spaces. Is there a trick to
> > dynamically space it correctly based on the data provided?
>
> it should be enough to update function:
> void hists__calc_col_len(struct hists *hists, struct hist_entry *h)
>
> with HISTC_MEM_DCACHELINE column update code, same as the rest
Ah, yes that worked perfectly. Will repost soon. :-)
Cheers,
Don
next prev parent reply other threads:[~2014-05-19 14:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 16:48 [PATCH 0/6 V2] perf: Enable mmap2 and add dcacheline sorting Don Zickus
2014-05-13 16:48 ` [PATCH 1/6] events, perf: Pass protection and flags bits through mmap2 interface Don Zickus
2014-05-16 12:22 ` Peter Zijlstra
2014-05-16 13:33 ` Don Zickus
2014-05-16 15:45 ` Peter Zijlstra
2014-05-16 16:20 ` Don Zickus
2014-05-13 16:48 ` [PATCH 2/6] Revert "perf: Disable PERF_RECORD_MMAP2 support" Don Zickus
2014-05-16 11:25 ` Jiri Olsa
2014-05-16 13:26 ` Don Zickus
2014-05-19 11:45 ` Jiri Olsa
2014-05-19 11:21 ` Jiri Olsa
2014-05-13 16:48 ` [PATCH 3/6] perf: Update mmap2 interface with protection and flag bits Don Zickus
2014-05-13 16:48 ` [PATCH 4/6] perf report: Add mem-mode documentation to report command Don Zickus
2014-05-13 16:48 ` [PATCH 5/6] perf: Add cpumode to struct hist_entry Don Zickus
2014-05-13 16:48 ` [PATCH 6/6] perf: Add dcacheline sort Don Zickus
2014-05-16 11:47 ` Jiri Olsa
2014-05-16 13:30 ` Don Zickus
2014-05-16 14:05 ` Jiri Olsa
2014-05-16 14:30 ` Don Zickus
2014-05-19 13:34 ` Jiri Olsa
2014-05-19 14:18 ` Don Zickus [this message]
2014-05-16 14:09 ` Stephane Eranian
2014-05-16 15:18 ` Don Zickus
2014-05-16 15:59 ` Peter Zijlstra
2014-05-16 16:02 ` Stephane Eranian
2014-05-16 16:24 ` Don Zickus
2014-05-16 16:27 ` Stephane Eranian
2014-05-19 11:25 ` Jiri Olsa
2014-05-19 13:20 ` Don Zickus
2014-05-13 16:52 ` [PATCH 0/6 V2] perf: Enable mmap2 and add dcacheline sorting 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=20140519141837.GI50500@redhat.com \
--to=dzickus@redhat.com \
--cc=acme@ghostprotocols.net \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@gmail.com \
--cc=peterz@infradead.org \
/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.