From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Tvrtko Ursulin <tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Johannes Weiner"
<hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
"Zefan Li" <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
"Dave Airlie" <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Daniel Vetter" <daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
"Rob Clark" <robdclark-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"Stéphane Marchesin"
<marcheu-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"T . J . Mercier"
<tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Kenny.Ho-5C7GfCeVMHo@public.gmane.org,
"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
"Brian Welty"
<brian.welty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Tvrtko Ursulin"
<tvrtko.ursulin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Eero Tamminen"
<eero.t.tamminen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rob Clark" <robdclark@chromium.org>,
Kenny.Ho@amd.com, "Dave Airlie" <airlied@redhat.com>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
Intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
cgroups@vger.kernel.org,
"Eero Tamminen" <eero.t.tamminen@intel.com>,
"T . J . Mercier" <tjmercier@google.com>
Subject: Re: [Intel-gfx] [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
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rob Clark" <robdclark@chromium.org>,
Kenny.Ho@amd.com, "Dave Airlie" <airlied@redhat.com>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
Intel-gfx@lists.freedesktop.org,
"Brian Welty" <brian.welty@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
cgroups@vger.kernel.org,
"Eero Tamminen" <eero.t.tamminen@intel.com>,
"T . J . Mercier" <tjmercier@google.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
WARNING: multiple messages have this Message-ID (diff)
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: 156+ 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 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 05/17] drm/i915: Implement fdinfo memory stats printing Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 06/17] drm: Update file owner during use Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 07/17] cgroup: Add the DRM cgroup controller Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 08/17] drm/cgroup: Track DRM clients per cgroup Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-21 22:14 ` Tejun Heo
2023-07-21 22:14 ` Tejun Heo
2023-07-21 22:14 ` Tejun Heo
2023-07-21 22:14 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:45 ` [PATCH 10/17] drm/cgroup: Add over budget signalling callback Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " 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:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` Tvrtko Ursulin
2023-07-12 11:45 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:46 ` [PATCH 12/17] cgroup/drm: Introduce weight based drm cgroup control Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-21 22:17 ` Tejun Heo
2023-07-21 22:17 ` Tejun Heo
2023-07-21 22:17 ` Tejun Heo
2023-07-21 22:17 ` [Intel-gfx] " Tejun Heo
[not found] ` <ZLsEEYDFlJZwrJiV-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-07-25 13:46 ` Tvrtko Ursulin
2023-07-25 13:46 ` Tvrtko Ursulin
2023-07-25 13:46 ` Tvrtko Ursulin
2023-07-25 13:46 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [Intel-gfx] " 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 ` Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 11:46 ` [PATCH 15/17] cgroup/drm: Expose GPU utilisation Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <20230712114605.519432-16-tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-21 22:19 ` Tejun Heo
2023-07-21 22:19 ` Tejun Heo
2023-07-21 22:19 ` Tejun Heo
2023-07-21 22:19 ` [Intel-gfx] " Tejun Heo
[not found] ` <ZLsEdJeEAPYWFunT-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2023-07-21 22:20 ` Tejun Heo
2023-07-21 22:20 ` Tejun Heo
2023-07-21 22:20 ` Tejun Heo
2023-07-21 22:20 ` [Intel-gfx] " Tejun Heo
2023-07-25 14:08 ` Tvrtko Ursulin
2023-07-25 14:08 ` Tvrtko Ursulin
2023-07-25 14:08 ` Tvrtko Ursulin
2023-07-25 14:08 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <3b96cada-3433-139c-3180-1f050f0f80f3-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-25 21:44 ` Tejun Heo [this message]
2023-07-25 21:44 ` Tejun Heo
2023-07-25 21:44 ` Tejun Heo
2023-07-25 21:44 ` [Intel-gfx] " Tejun Heo
2023-07-12 11:46 ` [PATCH 16/17] cgroup/drm: Expose memory stats Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <20230712114605.519432-17-tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-21 22:21 ` Tejun Heo
2023-07-21 22:21 ` Tejun Heo
2023-07-21 22:21 ` Tejun Heo
2023-07-21 22:21 ` [Intel-gfx] " Tejun Heo
2023-07-26 10:14 ` Maarten Lankhorst
2023-07-26 10:14 ` Maarten Lankhorst
2023-07-26 10:14 ` [Intel-gfx] " Maarten Lankhorst
2023-07-26 11:41 ` Tvrtko Ursulin
2023-07-26 11:41 ` Tvrtko Ursulin
2023-07-26 11:41 ` Tvrtko Ursulin
2023-07-26 11:41 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <89d7181c-6830-ca6e-0c39-caa49d14d474-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-27 11:54 ` Maarten Lankhorst
2023-07-27 11:54 ` Maarten Lankhorst
2023-07-27 11:54 ` Maarten Lankhorst
2023-07-27 11:54 ` [Intel-gfx] " Maarten Lankhorst
2023-07-27 17:08 ` Tvrtko Ursulin
2023-07-27 17:08 ` Tvrtko Ursulin
2023-07-27 17:08 ` Tvrtko Ursulin
2023-07-27 17:08 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <5d65d387-2718-06c3-ee5d-8a7da6e3ddfd-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-28 14:15 ` Tvrtko Ursulin
2023-07-28 14:15 ` Tvrtko Ursulin
2023-07-28 14:15 ` Tvrtko Ursulin
2023-07-28 14:15 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <ea64d7bf-c01b-f4ad-a36b-f77e2c2ea931-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-26 19:44 ` Tejun Heo
2023-07-26 19:44 ` Tejun Heo
2023-07-26 19:44 ` Tejun Heo
2023-07-26 19:44 ` [Intel-gfx] " Tejun Heo
2023-07-27 13:42 ` Maarten Lankhorst
2023-07-27 13:42 ` Maarten Lankhorst
2023-07-27 13:42 ` Maarten Lankhorst
2023-07-27 13:42 ` [Intel-gfx] " Maarten Lankhorst
[not found] ` <05178cf3-df1c-80a7-12ad-816fafbc2df7-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-27 16:43 ` Tvrtko Ursulin
2023-07-27 16:43 ` Tvrtko Ursulin
2023-07-27 16:43 ` Tvrtko Ursulin
2023-07-27 16:43 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-26 16:44 ` Tvrtko Ursulin
2023-07-26 16:44 ` Tvrtko Ursulin
2023-07-26 16:44 ` Tvrtko Ursulin
2023-07-26 16:44 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <8959f665-4353-3630-a6c7-5dca60959faa-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-26 19:49 ` Tejun Heo
2023-07-26 19:49 ` Tejun Heo
2023-07-26 19:49 ` Tejun Heo
2023-07-26 19:49 ` [Intel-gfx] " Tejun Heo
2023-07-12 11:46 ` [PATCH 17/17] drm/i915: Wire up to the drm cgroup " Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` Tvrtko Ursulin
2023-07-12 11:46 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-12 14:46 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for DRM cgroup controller with scheduling control and " Patchwork
2023-07-19 20:31 ` [RFC v5 00/17] " T.J. Mercier
2023-07-19 20:31 ` T.J. Mercier
2023-07-19 20:31 ` T.J. Mercier
2023-07-19 20:31 ` [Intel-gfx] " T.J. Mercier
[not found] ` <CABdmKX1PUF+X897ZMOr0RNiYdoiL_2NkcSt+Eh55BfW-05LopQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-07-20 10:55 ` Tvrtko Ursulin
2023-07-20 10:55 ` Tvrtko Ursulin
2023-07-20 10:55 ` Tvrtko Ursulin
2023-07-20 10:55 ` [Intel-gfx] " Tvrtko Ursulin
[not found] ` <95de5c1e-f03b-8fb7-b5ef-59ac7ca82f31-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-07-20 17:22 ` T.J. Mercier
2023-07-20 17:22 ` T.J. Mercier
2023-07-20 17:22 ` T.J. Mercier
2023-07-20 17:22 ` [Intel-gfx] " 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-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=Intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=Kenny.Ho-5C7GfCeVMHo@public.gmane.org \
--cc=airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=brian.welty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=daniel.vetter-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=eero.t.tamminen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
--cc=marcheu-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=robdclark-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=tvrtko.ursulin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.