All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@gmail.com>
To: Florian Fischer <florian.fischer@muhq.space>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-perf-users <linux-perf-users@vger.kernel.org>,
	Ian Rogers <irogers@google.com>,
	Xing Zhengjun <zhengjun.xing@linux.intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCHSET v4 next 0/3] perf stat: add user_time and system_time tool events
Date: Mon, 25 Apr 2022 12:06:53 -0700	[thread overview]
Message-ID: <CAM9d7cgcx42xD8QxOB+JBEL85mZU_va8FMiF31SRxABH8CakLg@mail.gmail.com> (raw)
In-Reply-To: <20220423121557.z5gzbqadonmrg6ef@pasture>

On Sat, Apr 23, 2022 at 5:16 AM Florian Fischer
<florian.fischer@muhq.space> wrote:
>
> On 22.04.2022 16:52, Namhyung Kim wrote:
> > Hello,
> >
> > On Fri, Apr 22, 2022 at 3:05 PM Arnaldo Carvalho de Melo
> > <acme@kernel.org> wrote:
> > >
> > > Em Wed, Apr 20, 2022 at 12:23:51PM +0200, Florian Fischer escreveu:
> > > > This patch series adds new internal events to perf stat exposing the times spend
> > > > in user and kernel mode in nanoseconds reported by rusage.
> > > >
> > > > During some benchmarking using perf it bothered me that I could not easily
> > > > retrieve those times from perf stat when using the machine readable output.
> > > >
> > > > But perf definitely knows about those values because in the human readable output
> > > > they are present.
> > > >
> > > > Therefore I exposed the times reported by rusage via the new tool events:
> > > > user_time and system_time.
> > > >
> > > > This allows to retrieved them in machine-readable output:
> > > >
> > > > $ ./perf stat -x, -e duration_time,user_time,system_time,cache-misses -- grep -q -r duration_time tools/perf
> > > > 72134524,ns,duration_time:u,72134524,100.00,,
> > > > 65225000,ns,user_time:u,65225000,100.00,,
> > > > 6865000,ns,ssystem_time:u,6865000,100.00,,

> > Anyway it looks a little bit strange to me if we can get
> > system time in user mode only (the 'u' modifier).
>
> Sorry but I don't really understand what you mean.
> The system_time is reported to userspace via rusage filled by wait4(2).
> It will always report the value reported to the user space regardless of what
> counters perf has access to.
>
> If you run perf as user you get the same system_time (but with the ':u' suffix)
> as when you run perf as root or lower kernel.perf_event_paranoid to allow access
> to more counters.

The ':u' modifier means that the event should count only in user mode.
So I think system_time:u should be 0 by definition.
Likewise, user_time:k should be handled as such.

But as I said before, we already have the task-clock event, so it's not
clear why we need this too.  Also these tool events won't work for
other use cases like perf record.

Thanks,
Namhyung

  reply	other threads:[~2022-04-25 19:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 10:23 [PATCHSET v4 next 0/3] perf stat: add user_time and system_time tool events Florian Fischer
2022-04-20 10:23 ` [PATCH v4 1/3] perf stat: introduce stats for the user and system rusage times Florian Fischer
2022-04-27  1:43   ` Ian Rogers
2022-04-20 10:23 ` [PATCH v4 2/3] perf stat: add user_time and system_time events Florian Fischer
2022-04-27  1:37   ` Ian Rogers
2022-04-20 10:23 ` [PATCH v4 3/3] perf list: print all available tool events Florian Fischer
2022-04-20 16:44   ` Arnaldo Carvalho de Melo
2022-04-20 17:42     ` [PATCH v5] " Florian Fischer
2022-04-20 17:42       ` Florian Fischer
2022-04-20 18:07         ` Arnaldo Carvalho de Melo
2022-04-20 16:46 ` [PATCHSET v4 next 0/3] perf stat: add user_time and system_time " Arnaldo Carvalho de Melo
2022-04-22 23:52   ` Namhyung Kim
2022-04-23 12:15     ` Florian Fischer
2022-04-25 19:06       ` Namhyung Kim [this message]
2022-04-26  8:58         ` Florian Fischer
2022-04-26 21:28           ` Namhyung Kim

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=CAM9d7cgcx42xD8QxOB+JBEL85mZU_va8FMiF31SRxABH8CakLg@mail.gmail.com \
    --to=namhyung@gmail.com \
    --cc=acme@kernel.org \
    --cc=florian.fischer@muhq.space \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=zhengjun.xing@linux.intel.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.