[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