public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@kernel.org, namhyung@kernel.org, eranian@google.com,
	Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 5/5] perf: Enable multiple hist_entry_group output
Date: Mon, 14 Apr 2014 10:13:36 -0400	[thread overview]
Message-ID: <20140414141336.GN8488@redhat.com> (raw)
In-Reply-To: <20140414091932.GC1433@krava.brq.redhat.com>

On Mon, Apr 14, 2014 at 11:19:32AM +0200, Jiri Olsa wrote:
> On Fri, Apr 11, 2014 at 02:34:52PM -0400, Don Zickus wrote:
> > On Fri, Apr 11, 2014 at 07:30:00PM +0200, Jiri Olsa wrote:
> 
> SNIP
> 
> > > and with your changes we could do:
> > > 
> > >    Overhead   CPU  symbol
> > >    ........   ...  ......
> > >    90%        0
> > >         50%        krava1
> > >         20%        krava2
> > >         30%        krava3
> > > 
> > >    10%        1
> > >         50%        krava4
> > >         50%        krava5
> > >   
> > > 
> > > I wonder we could go more generic and allow more nested groups,
> > > like eg allow group sort on cpu and pid (or more):
> > > 
> > >    Overhead   CPU  pid  symbol
> > >    ........   ...  ...  ......
> > >    90%        0
> > >       50%          100
> > >         50%             krava1
> > >         20%             krava2
> > >         30%             krava3
> > >       50%          110
> > >         50%             krava1
> > >         20%             krava2
> > >         30%             krava3
> > > 
> > >    10%        1
> > >       100%         200
> > >         50%             krava4
> > >         50%             krava5
> > > 
> > > 
> > > I glanced over the changes and I wonder we could do it
> > > by chaining hists structs via 'struct hist_entry'
> > > 
> > > like adding 'struct hists' into 'struct hists_entry'
> > > and making the sort_order local for each 'struct hists'
> > 
> > Unless you meant:
> > 
> > hists
> >  \- hist_entry
> >       \- hists
> >            \- hist_entry -> hist_entry -> hist_entry -> hist_entry
> >                               \- hists
> >                                    \- hist_entry -> hist_entry -> hist_entry
> > 
> > where each 'hists' represents a new group and a hist_entry->hists != NULL
> > is a group otherwise just a node?
> 
> right, hist_entry is either node or leaf, I see it like this:
> 
> hists (A)
>   \-hist_entry(A)->(hists B1)
>                      \-hist_entry(B1)
>                      \-hist_entry(B1)
>                      \-hist_entry(B1)
> 
>   \-hist_entry(A)->(hists B2)
>                      \-hist_entry(B2)
> 
>   \-hist_entry(A)->(hists B3)
>                      \-hist_entry(B3)
>                      \-hist_entry(B3)
> 
> 
> hists (A)  - getting data groupped by CPU - hist_entry (A)
> hists (BX) - getting data belonging to CPU group and groupped by symbol (hist_entry BX)
> 
> so hists(A) provides data for 1st column in Overhead,
> and hists(BX) provides data for the 2nd one:
> 
>   Overhead   CPU  symbol
>   ........   ...  ......
>   90%        0
>        50%        krava1
>        20%        krava2
>        30%        krava3
> 
>    5%        1
>       100%        krava4
> 
>    5%        2
>        50%        krava4
>        50%        krava5

Ok.  That at least tries to re-use the structs hist and hist_entry which
is what I struggled with when creating hist_entry_group.  Walking the
entries list will be an interesting challenge and sorting it.  I'll poke
it at it some more and see how things fall out.

Are you ok with the macros from patch 2?  At least the idea, we can change
the names.  I think I would like to continue with the macros to make it
easier to handle these changes, otherwise the code blows up and becomes
difficult to read.

Though I still am not sure how to handle 'pairs' correctly.

Cheers,
Don

  reply	other threads:[~2014-04-14 14:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10 20:10 [RFC 0/5] perf: Create hist_entry groups Don Zickus
2014-04-10 20:10 ` [RFC 1/5] perf: Wrap __hists__add_entry to prep for group entry change Don Zickus
2014-04-10 20:10 ` [RFC 2/5] perf: Use macros to walk hist entries Don Zickus
2014-04-10 20:10 ` [RFC 3/5] perf: Add in stub hist_entry_group code Don Zickus
2014-04-10 20:11 ` [RFC 4/5] perf: Switch to using hist_entry_group Don Zickus
2014-04-10 20:11 ` [RFC 5/5] perf: Enable multiple hist_entry_group output Don Zickus
2014-04-11 17:30   ` Jiri Olsa
2014-04-11 18:28     ` Don Zickus
2014-04-11 18:34     ` Don Zickus
2014-04-14  9:19       ` Jiri Olsa
2014-04-14 14:13         ` Don Zickus [this message]
2014-04-15  3:01 ` [RFC 0/5] perf: Create hist_entry groups Namhyung Kim
2014-04-15  9:40   ` Jiri Olsa
2014-04-15 11:35     ` Namhyung Kim
2014-04-15 16:08   ` Don Zickus
2014-04-16  8:29     ` Namhyung Kim
2014-04-21 20:07       ` 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=20140414141336.GN8488@redhat.com \
    --to=dzickus@redhat.com \
    --cc=acme@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox