public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: fche@redhat.com (Frank Ch. Eigler)
To: Stan Cox <scox@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: proposed perf.counter enhancement
Date: Tue, 23 Oct 2012 20:49:00 -0000	[thread overview]
Message-ID: <y0mobjs7w2m.fsf@fche.csb> (raw)
In-Reply-To: <50859301.6060409@redhat.com> (Stan Cox's message of "Mon, 22 Oct 2012 14:40:01 -0400")


Hi, Stan -


scox wrote:

> [...]
> // Define a perf counter of type X, config Y, sample_freq 0,
> // and task T.  Create a global z[cpu, i] to hold the counters.
> // Does not call _stp_perf_init as perf.type.config does, but calls it
> // later in process.begin
>
> probe perf.type(0).config(0).counter("y")
> {
> }

It would be nice to express per-cpu vs. per-thread counters.

> [...]
> // Define a reading counter probe.  Init the probe for the task:
> // _stp_perf_init (spr_perf_probes[n], task);
> // and generate an implicit read into the counter collector "z", ie
> //  for (i = 0; i < %{ num_online_cpus() %}; i++) {
> //      z[i, z_dims[i]++] = %{ _stp_perf_read(l->l_i) %}

What does the zdims[i]++ part mean?  Is it necessary to read the
counter values across all CPUs?

> // generate implicit read as above the term the counter: _stp_perf_del
> probe process("pwd").end.counter("z")
> {
> }

This doesn't make much sense to me.  The lifetime of some random
process "pwd" would need to spell out the relevance to some counter.


> // generate implicit read for process.function[.return]
> probe process("pwd").function("main").counter("y").counter("z")
> {
> }
>
> probe process("pwd").function("main").return.counter("y").counter("z")
> {
> }

I'd expect these probes to use the z variable somehow, perhaps to save
the deltas in some other array.  Plus, if from probe
perf...counter("z"), the translator understands that z is a special
variable, then perhaps it does not need markup of these counter-user
probes, just the mention of the variables.


> probe process("pwd").function("main").counter("y").counter("z")
> {
>    z <<< perf_read("z")
> }

(Recall though that the problem with a tapset function for this is
being invoked from atomic context.)


> probe end ()
> {
>    foreach (perf in z)
>       printf ("counter[%d] = %d\n", z[perf])
> }

(Wasn't z two-dimensional?)


By contrast, here's how I might imagine a similar scenario looking:

probe perf.type(0).config(0).per_thread("y") { }  # y implicit special local
global history
probe process("foobar").function("*").return { 
      index = tid() # or probefunc()
      history[index] <<< y-@entry(y) 
}
# let implicit global printing take care of [history] stats printing

  reply	other threads:[~2012-10-23 20:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 18:38 Stan Cox
2012-10-23 20:49 ` Frank Ch. Eigler [this message]
2012-11-02 18:54   ` Stan Cox
2012-11-19  4:58     ` Stan Cox
2012-11-19 19:16       ` Frank Ch. Eigler

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=y0mobjs7w2m.fsf@fche.csb \
    --to=fche@redhat.com \
    --cc=scox@redhat.com \
    --cc=systemtap@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).