Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

["Christian König" <christian.koenig@amd.com>]

Am 18.05.21 um 11:35 schrieb Tvrtko Ursulin:
>
> On 17/05/2021 19:02, Nieto, David M wrote:
>> [AMD Official Use Only]
>>
>>
>> The format is simple:
>>
>> <ringname><index>: <XXX.XX> %
>
> Hm what time period does the percent relate to?
>
> The i915 implementation uses accumulated nanoseconds active. That way 
> who reads the file can calculate the percentage relative to the time 
> period between two reads of the file.

That sounds much saner to me as well. The percentage calculation inside 
the kernel looks suspiciously misplaced.

>
>> we also have entries for the memory mapped:
>> mem <ttm pool> : <size> KiB
>
> Okay so in general key values per line in text format. Colon as 
> delimiter.
>
> What common fields could be useful between different drivers and what 
> common naming scheme, in order to enable as easy as possible creation 
> of a generic top-like tool?
>
> driver: <ko name>
> pdev: <pci slot>
> ring-<name>: N <unit>
> ...
> mem-<name>: N <unit>
> ...
>
> What else?
> Is ring a good common name? We actually more use engine in i915 but I 
> am not really bothered about it.

I would prefer engine as well. We are currently in the process of moving 
away from kernel rings, so that notion doesn't make much sense to keep 
forward.

Christian.

>
> Aggregated GPU usage could be easily and generically done by userspace 
> by adding all rings and normalizing.
>
>> On my submission 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2021-May%2F063149.html&amp;data=04%7C01%7CChristian.Koenig%40amd.com%7Cbad72cde9a7248b20c7f08d919e03deb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637569273164210285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TW3HaPkqyr6jwhTUVRue3fGTyRfV4KnhEuRtTTI5fMY%3D&amp;reserved=0 
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2021-May%2F063149.html&amp;data=04%7C01%7CChristian.Koenig%40amd.com%7Cbad72cde9a7248b20c7f08d919e03deb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637569273164210285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=TW3HaPkqyr6jwhTUVRue3fGTyRfV4KnhEuRtTTI5fMY%3D&amp;reserved=0> I 
>> added a python script to print out the info. It has a CPU usage lower 
>> that top, for example.
>>
>> To be absolutely honest, I agree that there is an overhead, but It 
>> might not be as much as you fear.
>
> For me more the issue is that the extra number of operations grows 
> with the number of open files on the system, which has no relation to 
> the number of drm clients.
>
> Extra so if the monitoring tool wants to show _only_ DRM processes. 
> Then the cost scales with total number of processes time total number 
> of files on the server.
>
> This design inefficiency bothers me yes. This is somewhat alleviated 
> by the proposal from Chris 
> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F419042%2F%3Fseries%3D86692%26rev%3D1&amp;data=04%7C01%7CChristian.Koenig%40amd.com%7Cbad72cde9a7248b20c7f08d919e03deb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637569273164210285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jNfe8h2BalOOc1Y0Idcs3wxnNOi74XhulkRlebmpgJM%3D&amp;reserved=0) 
> although there are downsides there as well. Like needing to keep a map 
> of pids to drm files in drivers.
>
> Btw what do you do in that tool for same fd in a multi-threaded process
> or so? Do you show duplicate entries or detect and ignore? I guess I 
> did not figure out if you show by pid/tgid or by fd.
>
> Regards,
>
> Tvrtko
>
>> ------------------------------------------------------------------------
>> *From:* Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> *Sent:* Monday, May 17, 2021 9:00 AM
>> *To:* Nieto, David M <David.Nieto@amd.com>; Daniel Vetter 
>> <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
>> *Cc:* Alex Deucher <alexdeucher@gmail.com>; Intel Graphics 
>> Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI 
>> developers <dri-devel@lists.freedesktop.org>
>> *Subject:* Re: [PATCH 0/7] Per client engine busyness
>>
>> On 17/05/2021 15:39, Nieto, David M wrote:
>>> [AMD Official Use Only]
>>>
>>>
>>> Maybe we could try to standardize how the different submission ring 
>>>    usage gets exposed in the fdinfo? We went the simple way of just 
>>> adding name and index, but if someone has a suggestion on how else 
>>> we could format them so there is commonality across vendors we could 
>>> just amend those.
>>
>> Could you paste an example of your format?
>>
>> Standardized fdinfo sounds good to me in principle. But I would also
>> like people to look at the procfs proposal from Chris,
>>    - link to which I have pasted elsewhere in the thread.
>>
>> Only potential issue with fdinfo I see at the moment is a bit of an
>> extra cost in DRM client discovery (compared to my sysfs series and also
>> procfs RFC from Chris). It would require reading all processes (well
>> threads, then maybe aggregating threads into parent processes), all fd
>> symlinks, and doing a stat on them to figure out which ones are DRM 
>> devices.
>>
>> Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.
>>
>>> I’d really like to have the process managers tools display GPU usage 
>>> regardless of what vendor is installed.
>>
>> Definitely.
>>
>> Regards,
>>
>> Tvrtko

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