From: Tejun Heo <tj@kernel.org>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Dave Airlie" <airlied@redhat.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Rob Clark" <robdclark@chromium.org>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"T . J . Mercier" <tjmercier@google.com>,
Kenny.Ho@amd.com, "Christian König" <christian.koenig@amd.com>,
"Brian Welty" <brian.welty@intel.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Eero Tamminen" <eero.t.tamminen@intel.com>
Subject: Re: [PATCH 15/17] cgroup/drm: Expose GPU utilisation
Date: Tue, 25 Jul 2023 11:44:12 -1000 [thread overview]
Message-ID: <ZMBCLJMLL_cl9G_e@slm.duckdns.org> (raw)
In-Reply-To: <3b96cada-3433-139c-3180-1f050f0f80f3@linux.intel.com>
Hello,
On Tue, Jul 25, 2023 at 03:08:40PM +0100, Tvrtko Ursulin wrote:
> > Also, shouldn't this be keyed by the drm device?
>
> It could have that too, or it could come later. Fun with GPUs that it not
> only could be keyed by the device, but also by the type of the GPU engine.
> (Which are a) vendor specific and b) some aree fully independent, some
> partially so, and some not at all - so it could get complicated semantics
> wise really fast.)
I see.
> If for now I'd go with drm.stat/usage_usec containing the total time spent
> how would you suggest adding per device granularity? Files as documented
> are either flag or nested, not both at the same time. So something like:
>
> usage_usec 100000
> card0 usage_usec 50000
> card1 usage_usec 50000
>
> Would or would not fly? Have two files along the lines of drm.stat and drm.dev_stat?
Please follow one of the pre-defined formats. If you want to have card
identifier and field key, it should be a nested keyed file like io.stat.
> While on this general topic, you will notice that for memory stats I have
> _sort of_ nested keyed per device format, for example on integrated Intel
> GPU:
>
> $ cat drm.memory.stat
> card0 region=system total=12898304 shared=0 active=0 resident=12111872 purgeable=167936
> card0 region=stolen-system total=0 shared=0 active=0 resident=0 purgeable=0
>
> If one a discrete Intel GPU two more lines would appear with memory
> regions of local and local-system. But then on some server class
> multi-tile GPUs even further regions with more than one device local
> memory region. And users do want to see this granularity for container use
> cases at least.
>
> Anyway, this may not be compatible with the nested key format as
> documented in cgroup-v2.rst, although it does not explicitly say.
>
> Should I cheat and create key names based on device and memory region name
> and let userspace parse it? Like:
>
> $ cat drm.memory.stat
> card0.system total=12898304 shared=0 active=0 resident=12111872 purgeable=167936
> card0.stolen-system total=0 shared=0 active=0 resident=0 purgeable=0
Yeah, this looks better to me. If they're reporting different values for the
same fields, they're separate keys.
Thanks.
--
tejun
next prev parent reply other threads:[~2023-07-25 21:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 11:45 [RFC v5 00/17] DRM cgroup controller with scheduling control and memory stats Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 01/17] drm/i915: Add ability for tracking buffer objects per client Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 02/17] drm/i915: Record which client owns a VM Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 03/17] drm/i915: Track page table backing store usage Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 04/17] drm/i915: Account ring buffer and context state storage Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 05/17] drm/i915: Implement fdinfo memory stats printing Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 06/17] drm: Update file owner during use Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 07/17] cgroup: Add the DRM cgroup controller Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 08/17] drm/cgroup: Track DRM clients per cgroup Tvrtko Ursulin
2023-07-21 22:14 ` Tejun Heo
2023-07-12 11:45 ` [PATCH 09/17] drm/cgroup: Add ability to query drm cgroup GPU time Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 10/17] drm/cgroup: Add over budget signalling callback Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 11/17] drm/cgroup: Only track clients which are providing drm_cgroup_ops Tvrtko Ursulin
2023-07-12 11:46 ` [PATCH 12/17] cgroup/drm: Introduce weight based drm cgroup control Tvrtko Ursulin
2023-07-21 22:17 ` Tejun Heo
2023-07-25 13:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [PATCH 13/17] drm/i915: Wire up with drm controller GPU time query Tvrtko Ursulin
2023-07-12 11:46 ` [PATCH 14/17] drm/i915: Implement cgroup controller over budget throttling Tvrtko Ursulin
2023-07-12 11:46 ` [PATCH 15/17] cgroup/drm: Expose GPU utilisation Tvrtko Ursulin
2023-07-21 22:19 ` Tejun Heo
2023-07-21 22:20 ` Tejun Heo
2023-07-25 14:08 ` Tvrtko Ursulin
2023-07-25 21:44 ` Tejun Heo [this message]
2023-07-12 11:46 ` [PATCH 16/17] cgroup/drm: Expose memory stats Tvrtko Ursulin
2023-07-21 22:21 ` Tejun Heo
2023-07-26 10:14 ` Maarten Lankhorst
2023-07-26 11:41 ` Tvrtko Ursulin
2023-07-27 11:54 ` Maarten Lankhorst
2023-07-27 17:08 ` Tvrtko Ursulin
2023-07-28 14:15 ` Tvrtko Ursulin
2023-07-26 19:44 ` Tejun Heo
2023-07-27 13:42 ` Maarten Lankhorst
2023-07-27 16:43 ` Tvrtko Ursulin
2023-07-26 16:44 ` Tvrtko Ursulin
2023-07-26 19:49 ` Tejun Heo
2023-07-12 11:46 ` [PATCH 17/17] drm/i915: Wire up to the drm cgroup " Tvrtko Ursulin
2023-07-19 20:31 ` [RFC v5 00/17] DRM cgroup controller with scheduling control and " T.J. Mercier
2023-07-20 10:55 ` Tvrtko Ursulin
2023-07-20 17:22 ` T.J. Mercier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZMBCLJMLL_cl9G_e@slm.duckdns.org \
--to=tj@kernel.org \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=Kenny.Ho@amd.com \
--cc=airlied@redhat.com \
--cc=brian.welty@intel.com \
--cc=cgroups@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=eero.t.tamminen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=marcheu@chromium.org \
--cc=robdclark@chromium.org \
--cc=tjmercier@google.com \
--cc=tvrtko.ursulin@intel.com \
--cc=tvrtko.ursulin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox