All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Robert Bragg <robert@sixbynine.org>
Cc: 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: Thu, 30 Oct 2014 20:08:41 +0100	[thread overview]
Message-ID: <20141030190841.GI23531@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <1413991731-20628-1-git-send-email-robert@sixbynine.org>

On Wed, Oct 22, 2014 at 04:28:48PM +0100, Robert Bragg wrote:
> Our desired permission model seems consistent with perf's current model
> whereby you would need privileges if you want to profile across all gpu
> contexts but not need special permissions to profile your own context.
> 
> The awkward part is that it doesn't make sense for us to have userspace
> open a perf event with a specific pid as the way to avoid needing root
> permissions because a side effect of doing this is that the events will
> be dynamically added/deleted so as to only monitor while that process is
> scheduled and that's not really meaningful when we're monitoring the
> gpu.

There is precedent in PERF_FLAG_PID_CGROUP to replace the pid argument
with a fd to your object.

And do I take it right that if you're able/allowed/etc.. to open/have
the fd to the GPU/DRM/DRI whatever context you have the right
credentials to also observe these counters?

> Conceptually I suppose we want to be able to open an event that's not
> associated with any cpu or process, but to keep things simple and fit
> with perf's current design, the pmu I have a.t.m expects an event to be
> opened for a specific cpu and unspecified process.

There are no actual scheduling ramifications right? Let me ponder his
for a little while more..

  parent reply	other threads:[~2014-10-30 19:08 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 [this message]
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

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=20141030190841.GI23531@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.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=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 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.