linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).