Re: [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Sagar Arun Kamble <sagar.a.kamble@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2225 bytes --]



On 12/21/2017 6:29 PM, Lionel Landwerlin wrote:
> Some more findings I made while playing with this series & GPUTop.
> Turns out the 2ms drift per second is due to timecounter. Adding the 
> delta this way :
>
> https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607
>
> Eliminates the drift.
I see two imp. changes 1. approximation of start time during 
init_timecounter 2. overflow handling in delta accumulation.
With these incorporated, I guess timecounter should also work in same 
fashion.
> Timelines of perf i915 tracepoints & OA reports now make a lot more sense.
>
> There is still the issue that reading the CPU clock & the RCS 
> timestamp is inherently not atomic. So there is a delta there.
> I think we should add a new i915 perf record type to express the delta 
> that we measure this way :
>
> https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R2475
>
> So that userspace knows there might be a global offset between the 2 
> times and is able to present it.
agree on this. Delta ns1-ns0 can be interpreted as max drift.
> Measurement on my KBL system were in the order of a few microseconds 
> (~30us).
> I guess we might be able to setup the correlation point better 
> (masking interruption?) to reduce the delta.
already using spin_lock. Do you mean NMI?
>
> Thanks,
>
> -
> Lionel
>
>
> On 07/12/17 00:57, Robert Bragg wrote:
>>
>>
>> On Thu, Dec 7, 2017 at 12:48 AM, Robert Bragg <robert@sixbynine.org 
>> <mailto:robert@sixbynine.org>> wrote:
>>
>>
>>     at least from what I wrote back then it looks like I was seeing a
>>     drift of a few milliseconds per second on SKL. I vaguely recall
>>     it being much worse given the frequency constants we had for Haswell.
>>
>>
>> Sorry I didn't actually re-read my own message properly before 
>> referencing it :) Apparently the 2ms per second drift was for 
>> Haswell, so presumably not quite so bad for SKL.
>>
>> - Robert
>>
>>
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>


[-- Attachment #1.2: Type: text/html, Size: 5592 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx