[Intel-gfx] [igt-dev] [PATCH i-g-t v2] intel-gpu-top: Rewrite the tool to be safe to use
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Apr 4 15:24:37 UTC 2018
On 04/04/2018 15:23, Eero Tamminen wrote:
> Hi,
>
> On 04.04.2018 15:42, Tvrtko Ursulin wrote:
>> On 04/04/2018 13:15, Eero Tamminen wrote:
>>> I've now tested v5 with old Ubuntu kernel on KBL, and with latest
>>> drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.
>>>
>>>
>>> Generic test results
>>> --------------------
>>>
>>> * Tool works on all of them
>>>
>>> * The new error messages and headings look good
>>>
>>> * Idle IMC read amounts correspond to expected values on SNB & HSW.
>>> The much smaller values on BDW & SKL are due to FBC (how well
>>> it compresses, naturally depends on screen content).
>
> Unlike I assumed earlier, it's not actually uncore bandwidth.
> It's RAM bandwidth, I guess the IMC abbreviation is for something
> like Intel/Integrated Memory Controller.
>
> Note that it includes also any memory bandwidth used by CPU, and if
> the data fits into LLC, it doesn't show it.
>
> However, knowing whether CPU uses memory bandwidth is actually useful
> thing because RAM bandwidth is a shared resource with GPU. One can
> check other tasks bandwidth usage before launching the GPU task.
>
>
>> Hm OK, you managed to explain it. Because in the meantime I have
>> observed one oddity with write bandwidth on my headless SkullCanyon
>> NUC. It idles around 28MiB/s,
>
> On idle machine, write bandwidth usage should be zero.
>
> What is causing the writes?
It was probably caused by some of the kernel debug options I had set. Or
maybe disabled dynticks. With fewer debug options and dynticks I cannot
reproduce that any more.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list