From: Steven Rostedt <rostedt@goodmis.org>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH v3 4/5] trace-cmd split: Enable support for buffer selection
Date: Thu, 1 Feb 2024 21:17:40 -0500 [thread overview]
Message-ID: <20240201211740.33b43bcd@gandalf.local.home> (raw)
In-Reply-To: <eb976812-06e9-4a0a-93d1-1868ee9d19e1@arm.com>
On Fri, 26 Jan 2024 09:54:53 +0100
Pierre Gondois <pierre.gondois@arm.com> wrote:
> Hello Steven,
>
Hi Pierre,
Sorry for the late reply. I've been putting out fires (you can read LWN or
The Register to see what exactly I was doing).
> On 1/25/24 18:10, Steven Rostedt wrote:
> > On Thu, 25 Jan 2024 11:51:47 -0500
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> >> Now if I had had:
> >>
> >> trace-cmd split -i /work/traces/trace-tast.dat --top -B tast -o /tmp/trace-tast2.dat
> >>
> >> Then because there was a command "--top" before the -B but it had no -o
> >> assigned for it, then the input_file would be considered the output file
> >> and that should act like you described.
> >
> > Of course then things get confusing if we were to have:
> >
> > trace-cmd split -i /work/traces/trace-tast.dat -B foo -o /tmp/trace-foo.dat -B bar
> >
> > We could specify that each -B will just use the top level by default. So
> > the above would create:
> >
> > /tmp/trace-foo.dat
> >
> > With the instance "foo"
> >
> > But the "bar" would be in:
> >
> > /work/traces/trace-tast.dat.bar
> >
> > because the top level didn't specify a -o.
> >
> > So to make it more specific. Each -B will default to the toplevel output
> > with ".<instance>" appended to it.
> >
> > That is:
> >
> > split <top-level-commands> -B instance1 <instance1-commands> -B <instance2-commands>
> >
> > If a -o is specified in the <top-level-commands> it becomes the default top
> > level output file. If a -o is not specified in any of the
> > <instance*-commands> then, it will default to the top level output file
> > with ".<instance-name>" attached to it unless it has its own -o specified.
>
> I also wanted to handle the case where multiple instances could be placed
> in an output file. Meaning that with the patches:
> - -B/--top options are parsed to select the instances to keep,
> - a -o option ends the parsing of instances and place them in the given output
> file. If no -o option is parsed, then the default output file or the input
> file is used as a base name for the last generated output file (i.e. trace.dat.1
> if no input file is specified)
OK, I see what you want. You want to be able to have multiple buffers in a
single file.
>
> ---
>
> For example, with a trace recorded with:
> $ trace-cmd record -e sched_wakeup -B switch_instance -e sched_switch -B timer_instance -e timer
>
> Creating a test.dat file containing the top instance and
> the switch_instance:
> $ trace-cmd split --top -B switch_instance -o test.dat
>
> Creating a test.dat file containing the switch_instance as
> the top instance, and the initial top instance as an instance
> named 'old_top':
> $ trace-cmd split -B switch_instance --top=old_top -o test.dat
>
> Splitting all instances in different .dat files:
> $ trace-cmd split --top -o top.dat -B switch_instance -o switch.dat -B timer_instance -o timer.dat
>
> And by default, if no -B/--top is specified for an output file,
> keep all the instances (but of course all the other options provided
> to the split command are applied, i.e. start/end timings):
> Keep all the instances and place them in test.dat:
> $ trace-cmd split -o test.dat
> Keep all the instances and place them in the default file trace.dat.1:
> $ trace-cmd split
>
> ---
>
> Maybe the list of generated files should be printed to avoid what happened
> to you, i.e. generating files that were not expected.
> I think that having a default name with a suffix being the top instance
> is a good idea, but I don't think it would be possible to parse the command
> line to have 2 instances in one file in such case.
>
> >
> > For multi-file splits, it will append ".0001", ".0002", etc to that file.
So what I'm thinking is that the -B buffers default to the same buffer as
the top buffer unless specified differently.
Here's what I think would work. We add four new options.
--top
-B <instance>
-t
-b
Where --top represents the "top" instance.
-B represents the <instance>
-t can be used after -B to make it a top instance.
-b can be used before any -B to make the top instance into its own instance.
Rules:
--top can not come after -B.
-t must come after -B
-b must come before -B
There can only be one top instance, and all named instances must be unique.
That is, you can't have two instances called "foo".
We have: trace-cmd split <TOP_COMMANDS> <INSTANCE_COMMANDS>
TOP_COMMANDS :: nil | TOP_PARAMS
INSTANCE_COMMANDS :: nil | -B name INSTANCE_PARAMS INSTANCE_COMMANDS
TOP_PARAMS :: nil | TOP_OPTIONS TOP_PARAMS
TOP_OPTIONS :: --top | -b name | -o file
INSTANCE_PARAMS :: nil | INSTANCE_OPTIONS INSTANCE_PARAMS
INSTANCE_OPTIONS :: nil | -t | -o file
Examples:
trace-cmd split --top -B foo
Will make a trace.dat.1 that has top and foo in it.
trace-cmd split --top
Will make a trace.dat.1 that only has the top instance
trace-cmd split -B foo
Will make a trace.dat.1 that only has foo in it.
trace-cmd split -B foo -t
Will make a trace.dat.1 that only has foo in it. It will also promote the
instance foo to the top instance (it will lose its "foo" name).
trace-cmd split --top -o buba.dat -B foo
Will create a buba.dat that has both top and foo in it
trace-cmd split --top -B foo -o buba.dat
Will create a trace-dat.1 with just top in it, and buba.dat with just foo
in it.
trace-cmd split --top -B foo -o buba.dat -t
Will create a trace-dat.1 with just top in it, and buba.dat with just foo
in it (promoting foo to top instance)
trace-cmd split --top -b foo -B foo -t
Will make a trace.dat.1 file where the top instance becomes "foo" and the
foo instance becomes the top instance.
trace-cmd split -o buba.dat -B foo -t
Will create just a buba.dat file with only foo in it, promoting it as the
top instance.
trace-cmd split -o buba.dat --top -B foo -o fooba.dat
Will create a buba.dat with just the top instance in it (note --top can
come before or after -o and that does not make any difference, but the
order of -B and -o does matter). It will also create a fooba.dat file with
just foo in it.
trace-cmd split --top -B foo -t -o fooba.dat -B bar
This will create a trace.dat.1 with the top instance and the bar instance,
but also make a fooba.dat file with just "foo", and promoting it as the top
instance.
trace-cmd split --top -o buba.dat -B foo -o foobar.dat -B bar -o foobar.dat
This will make two files. One with buba.dat that holds the top instance,
and foobar.dat that holds both the foo and bar instances.
trace-cmd split --top -o buba.dat -B foo -o foobar.dat -B bar -t -o foobar.dat
This will make two files. One with buba.dat that holds just the top
instance and a foobar.dat file that has both foo and bar, but bar gets
promoted to the top instance.
Does that make sense?
-- Steve
next prev parent reply other threads:[~2024-02-02 2:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 13:42 [PATCH v3 0/5] trace-cmd: split: Handle splitting files with multiple instances Pierre Gondois
2024-01-23 13:42 ` [PATCH v3 1/5] trace-cmd split: Store instances in local list Pierre Gondois
2024-01-23 13:42 ` [PATCH v3 2/5] trace-cmd split: Add functions to generate temp files Pierre Gondois
2024-01-23 13:42 ` [PATCH v3 3/5] trace-cmd split: Handle splitting files with multiple instances Pierre Gondois
2024-01-24 22:35 ` Steven Rostedt
2024-01-23 13:42 ` [PATCH v3 4/5] trace-cmd split: Enable support for buffer selection Pierre Gondois
2024-01-24 22:37 ` Steven Rostedt
2024-01-25 15:16 ` Pierre Gondois
2024-01-25 16:28 ` Steven Rostedt
2024-01-25 16:51 ` Steven Rostedt
2024-01-25 17:10 ` Steven Rostedt
2024-01-26 8:54 ` Pierre Gondois
2024-02-02 2:17 ` Steven Rostedt [this message]
2024-02-05 13:38 ` Pierre Gondois
2024-02-11 23:35 ` Steven Rostedt
2024-02-12 9:11 ` Pierre Gondois
2024-02-12 21:28 ` Steven Rostedt
2024-01-23 13:42 ` [PATCH v3 5/5] trace-cmd split: Update usage Pierre Gondois
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=20240201211740.33b43bcd@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=pierre.gondois@arm.com \
/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).