Quoting Tvrtko Ursulin (2017-07-26 11:34:49) > > On 20/07/2017 10:03, Tvrtko Ursulin wrote: > > On 19/07/2017 13:05, Chris Wilson wrote: > >> Quoting Tvrtko Ursulin (2017-07-18 15:36:04) > >>> From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>> > >>> Rough sketch of the idea I mentioned a few times to various people - > >>> merging > >>> the engine busyness tracking with Chris i915 PMU RFC. > >>> > >>> First patch is the actual PMU RFC by Chris. It is followed by some > >>> cleanup > >>> patches, then come a few improvements, cheap execlists engine > >>> busyness tracking, > >>> debugfs view for the same, and finally the i915 PMU is extended to > >>> use this > >>> instead of timer based mmio sampling. > >>> > >>> This makes it cheaper and also more accurate since engine busyness is > >>> not > >>> derived via sampling. > >>> > >>> But I haven't figure out the perf API yet. For example is it possible > >>> to access > >>> our events in an usable fashion via perf top/stat or something? Do we > >>> want to > >>> make the events discoverable as I did (patch 8). > >> > >> In my dreams I have gpu activity in the same perf timechart as gpu > >> activity. But that can be mostly by the request tracepoints, but still > >> overlaying cpu/gpu activity is desirable and more importantly we want to > >> coordinate with nouveau/amdgpu so that such interfaces are as agnostic > >> as possible. There are definitely a bunch of global features in common > >> for all (engine enumeration & activity, mempool enumeration, size & > >> activty, power usage?). But the key question is how do we build for the > >> future? Split the event id range into common/driver? > > > > I don't know if going for common events would be workable. A few metrics > > sounds like it could be generic, but I am not sure there would be more > > than a couple where that would be future proof. Also is the coordination > > effort (no one else seems to implement a perf interface at the moment) > > worth it at the current time? I am not sure. > > > >>> I could not find much (any?) kernel API level documentation for perf. > >> > >> There isn't much indeed. Given that we now have a second pair of eyes go > >> over the sampling and improve its interaction with i915, we should start > >> getting PeterZ involved to check the interaction with perf. > > > > Okay, I guess another cleanup pass and then I can do that. > > > > In the meantime do you have any good understanding of what kind of > > events are we exposing here? They look weird if I record them and look > > with "perf script", and "perf stat" always reports zeroes for them. But > > they still work from the overlay tool. So it is a bit of a mystery to me > > what they really are. > >>> Btw patch series actually works since intel-gpu-overlay can use these > >>> events > >>> when they are available. > >>> > >>> Chris Wilson (1): > >>> RFC drm/i915: Expose a PMU interface for perf queries > >> > >> One thing I would like is for any future interface (including this > >> engine/class/event id) to use the engine class/instance mapping. > > > > I was thinking about that myself. I can do it in the next cleanup pass. > > Although to do this I think it will make more sense for me to squash a > bunch of improvements into your patch, and to start working on it > directly. Your thoughts on this? Do you mind if I start working on the > original patch bumping its version number for all the additions? Don't mind in the slightest. I thought you had broken them out for a quick series of "oh, yes, completely missed that" to be squashed in when the patch is ready, and you feel comfortable on signing off on the whole thing. > This would mean squashing in probably the first eight patches from this > series. Followed by reworking it towards class-instance. And the rc6 > residency consolidation Sagar suggested. > > How do we keep shared authorship in this case? Can we have two From: > lines at the top? Take it. If you want leave a based on a patch by me, but 90% of the work is in the last 10% writing the patch, so you will be doing more work to bring the interface to a reality than I did. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
