Re: [PATCH 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 21, 2017 at 10:22:40AM +0000, Tvrtko Ursulin wrote:
> 
> On 21/02/2017 09:47, Chris Wilson wrote:
> >On Tue, Feb 21, 2017 at 09:13:49AM +0000, Tvrtko Ursulin wrote:
> >>@@ -593,6 +595,8 @@ static void intel_lrc_irq_handler(unsigned long data)
> >> 				execlists_context_status_change(port[0].request,
> >> 								INTEL_CONTEXT_SCHEDULE_OUT);
> >>
> >>+				trace_i915_gem_request_out(port[0].request,
> >>+							   portidx++);
> >
> >Not seeing the value in portidx here, since if we process this as two
> >seperate interrupts, it always comes out as 0. And 0 is what we expect.
> >Knowing that we processed more than one completion event inside a single
> >tasklet?
> 
> Yes, but I know that is very unlikely. In all the traces I have
> laying around here is is 546921 to 3 for port being zero. :)
> 
> Perhaps the fact can also be derived from the timestamps on trace
> events but it would be a bit of a heuristics. Sounds safer to just
> report the fact at source, but I can also remove it if you want.

I think I'd prefer it without portidx++. I just am not seeing the value
in it, whereas in[0] or in[1] clearly does have value. I also don't
think we are limiting ourselves to never adding extra information here.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux