All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Keeping <john@metanate.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-trace-devel@vger.kernel.org, williskung@google.com,
	kaleshsingh@google.com, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH 03/12] trace-cmd analyze: Show how much tasks run on each CPU
Date: Sat, 26 Mar 2022 11:07:03 +0000	[thread overview]
Message-ID: <Yj7z1zaDDlyHdg39@donbot> (raw)
In-Reply-To: <20220325161819.36de3bce@gandalf.local.home>

On Fri, Mar 25, 2022 at 04:18:19PM -0400, Steven Rostedt wrote:
> On Fri, 25 Mar 2022 19:36:24 +0000
> John Keeping <john@metanate.com> wrote:
> 
> > On Wed, Mar 23, 2022 at 10:57:17PM -0400, Steven Rostedt wrote:
> > > From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> > > 
> > > Display for each CPU that was traced, the amount of time tasks ran on
> > > them. Listing the tasks from the longest runner to the least.
> > > 
> > > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> > > ---
> > > +	for (i = 0; i < nr_tasks; i++) {
> > > +		task = cpu_tasks[i]->task;
> > > +
> > > +		if (!i) {
> > > +			printf("    Task name        PID \t     Run time\n");
> > > +			printf("    ---------        --- \t     --------\n");
> > > +		}
> > > +		printf("%16s %8d\t",
> > > +		       tep_data_comm_from_pid(tep, task->pid),
> > > +		       task->pid);
> > > +		print_time(cpu_tasks[i]->runtime, '_');
> > > +		printf(" (%%%lld)\n", (task->runtime * 100) / total_time);  
> > 
> > Is there a reason for using the CPU-specific runtime for the value and
> > the total runtime for the percentage?
> > 
> > I expected the percentage to be the percentage of this CPU's time spend
> > running the task.
> 
> We modify it so that each CPU has the same run time, unless there's missed
> events at the start (later patches), and then we change total_time to be
> the total time of the events on the CPU and not the entire trace.

I think we're talking about different things here, I probably wasn't
entirely clear about this.  It's the numerator of this division that I'm
concerned about and I wonder if this should be:

	(cpu_tasks[i]->runtime * 100) / total_time

If total_time is 10 seconds and there's a task A which runs on CPU0 for
2 seconds and CPU1 for 1 second then I expect to see:

	CPU 0
	A	2.000  (20%)

	CPU 1
	A	1.000  (10%)

But at the moment both of those lines will give 30% (although the actual
run times are correct).

  reply	other threads:[~2022-03-26 11:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-24  2:57 [PATCH 00/12] trace-cmd: Add trace-cmd analyze command Steven Rostedt
2022-03-24  2:57 ` [PATCH 01/12] trace-cmd: Add trace-cmd analyze Steven Rostedt
2022-03-28 16:08   ` Kalesh Singh
2022-03-28 16:34     ` Steven Rostedt
2022-03-24  2:57 ` [PATCH 02/12] trace-cmd analyze: Show what tasks are running the most Steven Rostedt
2022-03-24  2:57 ` [PATCH 03/12] trace-cmd analyze: Show how much tasks run on each CPU Steven Rostedt
2022-03-25 19:36   ` John Keeping
2022-03-25 20:18     ` Steven Rostedt
2022-03-26 11:07       ` John Keeping [this message]
2022-03-26 15:16         ` Steven Rostedt
2022-03-28 16:23           ` Kalesh Singh
2022-03-24  2:57 ` [PATCH 04/12] trace-cmd analyze: Use sched_switch to find comm mappings Steven Rostedt
2022-03-24  2:57 ` [PATCH 05/12] trace-cmd analyze: Use sched_switch event to update times Steven Rostedt
2022-03-24  2:57 ` [PATCH 06/12] trace-cmd analyze: Add tracing of tasks and their states Steven Rostedt
2022-03-25 19:37   ` John Keeping
2022-03-25 20:19     ` Steven Rostedt
2022-03-24  2:57 ` [PATCH 07/12] trace-cmd analyze: Add "idleness" Steven Rostedt
2022-03-24  2:57 ` [PATCH 08/12] trace-cmd analyze: Track migration Steven Rostedt
2022-03-24  2:57 ` [PATCH 09/12] trace-cmd analyze: Add wake up latency timings Steven Rostedt
2022-03-25 19:34   ` John Keeping
2022-03-25 20:13     ` Steven Rostedt
2022-03-25 20:31       ` Steven Rostedt
2022-03-26 11:14         ` John Keeping
2022-03-26 15:32           ` Steven Rostedt
2022-03-24  2:57 ` [PATCH 10/12] trace-cmd analyze: Add counting of page faults Steven Rostedt
2022-03-24  2:57 ` [PATCH 11/12] trace-cmd analyze: Account for dropped events Steven Rostedt
2022-03-24  2:57 ` [PATCH 12/12] trace-cmd analyze: Add documentation Steven Rostedt

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=Yj7z1zaDDlyHdg39@donbot \
    --to=john@metanate.com \
    --cc=kaleshsingh@google.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=williskung@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.