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
next prev parent 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).