public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Ashford <cjashfor@us.ibm.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux
Date: Fri, 05 Dec 2008 13:24:43 -0800	[thread overview]
Message-ID: <49399C1B.7000401@us.ibm.com> (raw)

> * Ingo Molnar <mingo@elte.hu> wrote:
> 
>> > >  - No interaction with ptrace: any task (with sufficient permissions) can
>> > >    monitor other tasks, without having to stop that task.
>> > 
>> > This isn't going to work.
>> >
>> > If you look at the things the perfmon libraries do, you do need to stop 
>> > the task.
>> >
>> > Consider counter virtualization as the most direct example. [...]
>> 
>> Note that counter virtualization is not offered in the perfmon3 patchset that has 
>> been posted to lkml. (It is part of the much larger 'full' perfmon patchset which 
>> has not been submitted for integration)
>> 
>> Nevertheless we will offer counter virtualization in -v2 of our patchset [...]
> 
> i've just implemented it. Running an (infinite-loop) hello.c with 6 counters on a 
> CPU that has only two counters now gives the expected:
> 
>  counter[0 cycles              ]:           3368245084 , delta: 842019470 events
>  counter[1 instructions        ]:           1384678210 , delta: 346108294 events
>  counter[2 cache-refs          ]:                  659 , delta: 150 events
>  counter[3 cache-misses        ]:                    0 
>  counter[4 branch-instructions ]:            266919398 , delta: 66731508 events
>  counter[5 branch-misses       ]:                 1201 , delta: 315 events
> 
> This will be in -v2.
> 
> 	Ingo
>

When you use the term "virtualization" here, I think you mean "event set 
multiplexing" in perfmon terms.  When perfmon talks about 
virtualization, it's the virtualizing of a small counter (e.g. 32-bits) 
to a 64-bit counter via its overflow interrupt.  And 64-bit counter 
support is included in the perfmon3 posted to LKML.

One thing that PAPI needs is some control over which events are in each 
event "set", to use a perfmon term.  In particular, it needs to have a 
cycles counter in each set so that it can properly scale the event 
counts at the time it reads them up.

With your proposal:

* Would there be a way to force a particular event to be in every event 
set that is scheduled onto the processor?

* When monitoring program reads up the counts, how would it find the 
individual cycles count for each set?

* How would it know which other events were in the same set?

* Would it force the round robin scheduling to only a single event 
(paired with the cycles event) in each set?

* On what basis is the round robin scheduling performed?  Time?  Upon 
the overflow of an event counter?  If there is more than one option, how 
is it specified and tweaked? If time is one of the options, how does the 
caller specify the the round-robin switching rate?

These are all things that are supported in a very flexible way in 
perfmon3 (full).

Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@us.ibm.com




             reply	other threads:[~2008-12-05 21:24 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-05 21:24 Corey Ashford [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-12-04 23:44 [patch 0/3] [Announcement] Performance Counters for Linux Thomas Gleixner
2008-12-05  0:22 ` Paul Mackerras
2008-12-05  6:31   ` Ingo Molnar
2008-12-05  7:02     ` Arjan van de Ven
2008-12-05  7:52       ` David Miller
2008-12-05  7:03     ` Ingo Molnar
2008-12-05  7:16       ` Peter Zijlstra
2008-12-05  7:57         ` Paul Mackerras
2008-12-05  8:03           ` Peter Zijlstra
2008-12-05  8:07             ` David Miller
2008-12-05  8:11               ` Ingo Molnar
2008-12-05  8:17                 ` David Miller
2008-12-05  8:24                   ` Ingo Molnar
2008-12-05  8:27                     ` David Miller
2008-12-05  8:42                       ` Ingo Molnar
2008-12-05  8:49                         ` David Miller
2008-12-05 12:13                           ` Ingo Molnar
2008-12-05 12:39                         ` Andi Kleen
2008-12-05 20:08                           ` David Miller
2008-12-10  3:48                             ` Paul Mundt
2008-12-10  4:42                               ` Paul Mackerras
2008-12-10  8:43                               ` Mikael Pettersson
2008-12-10 10:28                               ` Andi Kleen
2008-12-10 10:23                                 ` Paul Mundt
2008-12-10 11:03                                   ` Andi Kleen
2008-12-05 15:00               ` Arjan van de Ven
2008-12-05  9:16             ` Paul Mackerras
2008-12-05  7:57       ` David Miller
2008-12-05  8:18         ` Ingo Molnar
2008-12-05  8:20           ` David Miller
2008-12-05  7:54     ` Paul Mackerras
2008-12-05  8:08       ` Ingo Molnar
2008-12-05  8:15         ` David Miller
2008-12-05 13:25           ` Ingo Molnar
2008-12-05  9:10         ` Paul Mackerras
2008-12-05 12:07           ` Ingo Molnar
2008-12-06  0:05             ` Paul Mackerras
2008-12-06  1:23               ` Mikael Pettersson
2008-12-06 12:34               ` Peter Zijlstra
2008-12-07  5:15                 ` Paul Mackerras
2008-12-08  7:18                   ` stephane eranian
2008-12-08 11:11                     ` Ingo Molnar
2008-12-08 11:58                       ` David Miller
2008-12-09  0:21                       ` stephane eranian
2008-12-05  0:22 ` H. Peter Anvin
2008-12-05  0:43   ` Paul Mackerras
2008-12-05  1:12 ` David Miller
2008-12-05  6:10   ` Ingo Molnar
2008-12-05  7:50     ` David Miller
2008-12-05  9:34     ` Paul Mackerras
2008-12-05 10:41       ` Ingo Molnar
2008-12-05 10:05     ` Ingo Molnar
2008-12-05  3:30 ` Andrew Morton
2008-12-06  2:36 ` stephane eranian
2008-12-10 16:27   ` [perfmon2] " Rob Fowler
2008-12-10 17:11     ` Andi Kleen

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=49399C1B.7000401@us.ibm.com \
    --to=cjashfor@us.ibm.com \
    --cc=linux-kernel@vger.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