All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Ulrich Drepper <drepper@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	acme@redhat.com, a.p.zijlstra@chello.nl, mingo@elte.hu,
	paulus@samba.org, cjashfor@linux.vnet.ibm.com,
	fweisbec@gmail.com, linux-kernel@vger.kernel.org,
	tglx@linutronix.de
Subject: Re: [RFCv2 0/8] perf tool: Add new event group management
Date: Mon, 28 May 2012 21:21:57 +0200	[thread overview]
Message-ID: <20120528192157.GD9654@m.brq.redhat.com> (raw)
In-Reply-To: <CAOPLpQfveNoXkorqfk=zSp72-YXskxtDebJqhGarngaJY89Rmg@mail.gmail.com>

On Sun, May 27, 2012 at 03:56:22AM -0400, Ulrich Drepper wrote:
> On Sat, May 26, 2012 at 8:38 AM, Jiri Olsa <jolsa@redhat.com> wrote:
> > If you have some ideas on this or real world examples,
> > that would really help.. so far, here's the latest discussion:
> > http://marc.info/?t=133357436900005&r=1&w=2
> 
> If you're looking for a definitive source, just point to the Intel
> optimization manual.  Absolute values of counters are not really
> useful and so they are defining many (50+) ratios which people should
> investigate.  These ratios are only really accurate if the counters
> are swapped in and out at the same time.

thanks a lot for the pointer, very useful

> 
> The reminds me of a detail I looked at when starting an an
> implementation for this (glad you got more time to devote to it).  The
> problem with ratios are that there are so many.  So efficient
> scheduling is going to be important.  Many ratios use as a base the
> same counters over and over again (e.g., cycle count, instruction
> count, etc).  Therefore it is important to recognize when two groups
> can be scheduled concurrently even if the total number of counters
> needed would be high but due to intersections it is possible.
> 
> One last comment, not critical.  From a parsing point of view the
> colon in the proposed syntax
> 
>     name : { counter1, counter2 }
> 
> is unnecessary.  Just one more thing people can get wrong.  How about
> leaving it out?  An open curly brace to indicate a group should be
> sufficient.

yep, we'll omit the first colon

I'll CC you guys on next patchset

thanks,
jirka

  parent reply	other threads:[~2012-05-28 19:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 21:16 [RFCv2 0/8] perf tool: Add new event group management Jiri Olsa
2012-04-04 21:16 ` [PATCH 1/8] perf, tool: Add support to parse event group syntax Jiri Olsa
2012-04-04 21:16 ` [PATCH 2/8] perf, tool: Enable grouping logic for parsed events Jiri Olsa
2012-04-04 21:16 ` [PATCH 3/8] perf: Add PERF_EVENT_IOC_ID ioctl to return event ID Jiri Olsa
2012-04-04 21:16 ` [PATCH 4/8] perf, tool: Use PERF_EVENT_IOC_ID perf ioctl to read event id Jiri Olsa
2012-04-04 21:16 ` [PATCH 5/8] perf, tool: Separate 'mem:' event scanner bits Jiri Olsa
2012-04-11 13:28   ` Robert Richter
2012-04-11 14:33     ` Jiri Olsa
2012-04-13 17:02       ` Robert Richter
2012-04-04 21:16 ` [PATCH 6/8] perf, tool: Add modifier support to group event syntax Jiri Olsa
2012-04-04 21:16 ` [PATCH 7/8] perf, tool: Add support for parsing PERF_SAMPLE_READ Jiri Olsa
2012-04-04 21:16 ` [PATCH 8/8] perf, tool: Enable sampling on specified event group leader Jiri Olsa
2012-04-04 21:21 ` [RFCv2 0/8] perf tool: Add new event group management Jiri Olsa
2012-04-15 15:16 ` Peter Zijlstra
2012-04-16 12:16   ` Jiri Olsa
2012-04-16 14:23     ` Peter Zijlstra
2012-04-16 15:26     ` Peter Zijlstra
2012-04-16 15:37       ` Jiri Olsa
2012-04-17  2:16         ` Namhyung Kim
2012-04-17  9:09       ` Namhyung Kim
2012-04-17  9:33         ` Jiri Olsa
2012-05-25 22:36 ` Andi Kleen
2012-05-26 12:38   ` Jiri Olsa
2012-05-26 19:23     ` Andi Kleen
2012-05-27  7:56     ` Ulrich Drepper
2012-05-27 15:08       ` Andi Kleen
2012-05-28 19:21       ` Jiri Olsa [this message]
2012-05-29  8:39       ` Peter Zijlstra

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=20120528192157.GD9654@m.brq.redhat.com \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=drepper@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    /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.