From: Ingo Molnar <mingo@kernel.org>
To: Robert Bragg <robert@sixbynine.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Chris Wilson <chris@chris-wilson.co.uk>,
Rob Clark <robdclark@gmail.com>,
Samuel Pitoiset <samuel.pitoiset@gmail.com>,
Ben Skeggs <bskeggs@redhat.com>
Subject: Re: [RFC PATCH 0/3] Expose gpu counters via perf pmu driver
Date: Sun, 16 Nov 2014 10:27:37 +0100 [thread overview]
Message-ID: <20141116092737.GA19043@gmail.com> (raw)
In-Reply-To: <CAMou1-1NTyym0fzyT-QmOTMEW-Bu=vX8jLM83+=hGktqd1+Q+A@mail.gmail.com>
* Robert Bragg <robert@sixbynine.org> wrote:
> > I'd strong[ly] suggest thinking about sampling as well, if
> > the hardware exposes sample information: at least for
> > profiling CPU loads the difference is like day and night,
> > compared to aggregated counts and self-profiling.
>
> Here I was thinking of counters or data that can be sampled via
> mmio using a hrtimer. E.g. the current gpu frequency or the
> energy usage. I'm not currently aware of any capability for the
> gpu to say trigger an interrupt after a threshold number of
> events occurs (like clock cycles) so I think we may generally
> be limited to a wall clock time domain for sampling.
In general hrtimer-driven polling gives pretty good profiling
information as well - key is to be able to get a sample of EU
thread execution state.
(Trigger thresholds and so can be useful as well, but are a
second order concern in terms of profiling quality.)
> > It's a very good idea to not expose such limitations to
> > user-space - the GPU driver doing the necessary hrtimer
> > polling to construct a proper count is a much higher quality
> > solution.
>
> That sounds preferable.
>
> I'm open to suggestions for finding another way for userspace
> to initiate a flush besides through read() in case there's a
> concern that might be set a bad precedent. For the i915_oa
> driver it seems ok at the moment since we don't currently
> report a useful counter through read() and for the main use
> case where we want the flushing we expect that most of the time
> there won't be any significant cost involved in flushing since
> we'll be using a very low timer period. Maybe this will bite us
> later though.
You could add an ioctl() as well - we are not religious about
them, there's always things that are special enough to not
warrant a generic syscall.
Anyway, aggregate counts alone are obviously very useful to
analyzing GPU performance, so your initial approach looks
perfectly acceptable to me already.
Thanks,
Ingo
prev parent reply other threads:[~2014-11-16 9:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 15:28 [RFC PATCH 0/3] Expose gpu counters via perf pmu driver Robert Bragg
2014-10-22 15:28 ` [RFC PATCH 1/3] perf: export perf_event_overflow Robert Bragg
2014-10-22 15:28 ` [RFC PATCH 2/3] perf: Add PERF_PMU_CAP_IS_DEVICE flag Robert Bragg
2014-10-22 15:28 ` [RFC PATCH 3/3] i915: Expose PMU for Observation Architecture Robert Bragg
2014-10-23 7:47 ` Chris Wilson
2014-10-24 2:33 ` Robert Bragg
2014-10-24 6:56 ` Chris Wilson
2014-10-23 5:58 ` [RFC PATCH 0/3] Expose gpu counters via perf pmu driver Ingo Molnar
2014-10-24 13:39 ` Robert Bragg
2014-10-30 19:08 ` Peter Zijlstra
2014-11-03 21:47 ` Robert Bragg
2014-11-05 12:33 ` Peter Zijlstra
2014-11-06 0:37 ` Robert Bragg
2014-11-10 11:13 ` Ingo Molnar
2014-11-12 23:33 ` Robert Bragg
2014-11-16 9:27 ` Ingo Molnar [this message]
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=20141116092737.GA19043@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=bskeggs@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robdclark@gmail.com \
--cc=robert@sixbynine.org \
--cc=samuel.pitoiset@gmail.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).