[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141023055825.GA4559@gmail.com>
Date: Thu, 23 Oct 2014 07:58:25 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Robert Bragg <robert@...bynine.org>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Chris Wilson <chris@...is-wilson.co.uk>,
Rob Clark <robdclark@...il.com>,
Samuel Pitoiset <samuel.pitoiset@...il.com>,
Ben Skeggs <bskeggs@...hat.com>
Subject: Re: [RFC PATCH 0/3] Expose gpu counters via perf pmu driver
* Robert Bragg <robert@...bynine.org> wrote:
> [...]
>
> I'd be interested to hear whether is sounds reasonable to
> others for us to expose gpu device metrics via a perf pmu and
> whether adding the PERF_PMU_CAP_IS_DEVICE flag as in my
> following patch could be acceptable.
I think it's perfectly reasonable, it's one of the interesting
kernel features I hoped for years would be implemented for perf.
> [...]
>
> In addition I also explicitly black list numerous attributes
> and PERF_SAMPLE_ flags that I don't think make sense for a
> device pmu. This could be handled in the pmu driver but it
> seemed better to do in events/core, avoiding duplication in
> case we later have multiple device pmus.
Btw., if the GPU is able to dump (part of) its current execution
status, you could in theory even do instruction profiling and
in-GPU profiling (symbol resolution, maybe even annotation, etc.)
with close to standard perf tooling - which I think is currently
mostly the domain of proprietary tools.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists