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.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
