[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVE3shwiRbUQyAqs@mtj.duckdns.org>
Date: Sun, 12 Nov 2023 14:38:10 -0600
From: Tejun Heo <tj@...nel.org>
To: Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
Cc: Intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
Johannes Weiner <hannes@...xchg.org>,
Zefan Li <lizefan.x@...edance.com>,
Dave Airlie <airlied@...hat.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Rob Clark <robdclark@...omium.org>,
Stéphane Marchesin <marcheu@...omium.org>,
"T . J . Mercier" <tjmercier@...gle.com>, Kenny.Ho@....com,
Christian König <christian.koenig@....com>,
Brian Welty <brian.welty@...el.com>,
Tvrtko Ursulin <tvrtko.ursulin@...el.com>
Subject: Re: [RFC v6 0/8] DRM scheduling cgroup controller
Hello,
>From cgroup POV, it generally looks fine to me. As before, I'm really
curious whether this is something other non-intel drivers can get behind.
Just one nit.
On Tue, Oct 24, 2023 at 05:07:19PM +0100, Tvrtko Ursulin wrote:
> * Allowing per DRM card configuration and queries is deliberatly left out but
> it is compatible in principle with the current proposal.
>
> Where today we have, for drm.weight:
>
> 100
>
> We can later extend with:
>
> 100
> card0 80
> card1 20
>
> Similarly for drm.stat:
>
> usage_usec 1000
> card0.usage_usec 500
> card1.usage_usec 500
These dont't match what blkcg is doing. Please use nested keyed format
instead.
Thanks.
--
tejun
Powered by blists - more mailing lists