From: Ross Zwisler <zwisler@google.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH] libtraceeval: Add traceeval_stat_max/min_timestamp() API
Date: Wed, 11 Oct 2023 16:21:00 -0600 [thread overview]
Message-ID: <20231011222100.GA94116@google.com> (raw)
In-Reply-To: <20231005181448.176e9563@gandalf.local.home>
On Thu, Oct 05, 2023 at 06:14:48PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
>
> If a value field is flagged as a TIMESTAMP, and another field is flagged
> as a STAT, have the statistics for the STAT field automatically keep track
> of when the max and min happened (what the TIMESTAMP field was at those
> instances).
I'm confused as to why we have TRACEEVAL_FL_TIMESTAMP and a separate data
entry with that flag, instead of only storing the timestamp in the entry
metadata, as we do with the other STATs?
From the description above where we have one TIMESTAMP and one STAT, I would
expect to see structures defined like this
(from [PATCH v2] libtraceeval: Add wake-lat sample code):
+struct traceeval_type sched_vals[] = {
+ {
+ .name = "timestamp",
+ .flags = TRACEEVAL_FL_TIMESTAMP,
+ .type = TRACEEVAL_TYPE_NUMBER_64,
+ },
+ {
+ .name = "delta",
+ .flags = TRACEEVAL_FL_STAT,
+ .type = TRACEEVAL_TYPE_NUMBER_64,
+ }
where the timestamp is sync'd with the STAT min and max, right?
But we also have this:
+struct traceeval_type wakeup_vals[] = {
+ {
+ .name = "timestamp",
+ .flags = TRACEEVAL_FL_TIMESTAMP,
+ .type = TRACEEVAL_TYPE_NUMBER_64,
+ }
+};
in a structure that doesn't have a corresponding STAT field? This is also
confusing to me because we need to keep 2 values (min and max TS), but this
only holds one?
The timestamp is already stored independently in the stat metadata in
struct traceeval_stat:
> struct traceeval_stat {
> unsigned long long max;
> + unsigned long long max_ts;
> unsigned long long min;
> + unsigned long long min_ts;
> unsigned long long total;
> unsigned long long std;
> size_t count;
which I think is enough?
It seems like instead we really want our two flags to be:
TRACEEVAL_FL_STAT
and
TRACEEVAL_FL_STAT_TS
where the first just keeps the normal stats (min, max, average, std. dev, etc)
and the second does all that plus timestamps for min and max?
This would also allow you to keep min and max stats independently for multiple
entries in a single structure, i.e.:
struct traceeval_type task_vals[] = {
{
.name = "wake_delay",
.flags = TRACEEVAL_FL_STAT_TS,
.type = TRACEEVAL_TYPE_NUMBER_64,
},
{
.name = "runtime",
.flags = TRACEEVAL_FL_STAT_TS,
.type = TRACEEVAL_TYPE_NUMBER_64,
}
};
which I don't think is possible under the current scheme?
What am I missing?
next prev parent reply other threads:[~2023-10-11 22:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 22:14 [PATCH] libtraceeval: Add traceeval_stat_max/min_timestamp() API Steven Rostedt
2023-10-11 22:21 ` Ross Zwisler [this message]
2023-10-11 23:09 ` Steven Rostedt
2023-10-17 18:47 ` Ross Zwisler
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=20231011222100.GA94116@google.com \
--to=zwisler@google.com \
--cc=linux-trace-devel@vger.kernel.org \
--cc=rostedt@goodmis.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 NNTP newsgroup(s).