Re: [PATCH v7 0/6] Proposal for a GPU cgroup controller

From: "T.J. Mercier" <tjmercier@google.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org,
	"Carlos Llamas" <cmllamas@google.com>,
	dri-devel@lists.freedesktop.org,
	"John Stultz" <jstultz@google.com>,
	"Zefan Li" <lizefan.x@bytedance.com>,
	"Kalesh Singh" <kaleshsingh@google.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	Kenny.Ho@amd.com,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Martijn Coenen" <maco@android.com>,
	"Nicolas Dufresne" <nicolas@ndufresne.ca>,
	"Laura Abbott" <labbott@redhat.com>,
	kernel-team@android.com, linux-media@vger.kernel.org,
	"Todd Kjos" <tkjos@android.com>,
	linaro-mm-sig@lists.linaro.org,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	cgroups@vger.kernel.org, "Suren Baghdasaryan" <surenb@google.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, "Liam Mark" <lmark@codeaurora.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Hridya Valsaraju" <hridya@google.com>
Subject: Re: [PATCH v7 0/6] Proposal for a GPU cgroup controller
Date: Wed, 15 Jun 2022 10:31:21 -0700	[thread overview]
Message-ID: <CABdmKX0WV8VWgeafVGJ++nJ4xsJD7Wpz=3KX=BW1du=huttfvw@mail.gmail.com> (raw)
In-Reply-To: <CABdmKX2Ok023rN1drQgXVZLKUO_DVYrzmEamCgMMu6BPO67yhQ@mail.gmail.com>

On Fri, May 20, 2022 at 9:25 AM T.J. Mercier <tjmercier@google.com> wrote:
>
> On Fri, May 20, 2022 at 12:47 AM Tejun Heo <tj@kernel.org> wrote:
> >
> > Hello,
> >
> > On Tue, May 17, 2022 at 04:30:29PM -0700, T.J. Mercier wrote:
> > > Thanks for your suggestion. This almost works. "dmabuf" as a key could
> > > work, but I'd actually like to account for each heap. Since heaps can
> > > be dynamically added, I can't accommodate every potential heap name by
> > > hardcoding registrations in the misc controller.
> >
> > On its own, that's a pretty weak reason to be adding a separate gpu
> > controller especially given that it doesn't really seem to be one with
> > proper abstractions for gpu resources. We don't want to keep adding random
> > keys to misc controller but can definitely add limited flexibility. What
> > kind of keys do you need?
> >
> Well the dmabuf-from-heaps component of this is the initial use case.
> I was envisioning we'd have additional keys as discussed here:
> https://lore.kernel.org/lkml/20220328035951.1817417-1-tjmercier@google.com/T/#m82e5fe9d8674bb60160701e52dae4356fea2ddfa
> So we'd end up with a well-defined core set of keys like "system", and
> then drivers would be free to use their own keys for their own unique
> purposes which could be complementary or orthogonal to the core set.
> Yesterday I was talking with someone who is interested in limiting gpu
> cores and bus IDs in addition to gpu memory. How to define core keys
> is the part where it looks like there's trouble.
>
> For my use case it would be sufficient to have current and maximum
> values for an arbitrary number of keys - one per heap. So the only
> part missing from the misc controller (for my use case) is the ability
> to register a new key at runtime as heaps are added. Instead of
> keeping track of resources with enum misc_res_type, requesting a
> resource handle/ID from the misc controller at runtime is what I think
> would be required instead.
>
Quick update: I'm going to make an attempt to modify the misc
controller to support a limited amount of dynamic resource
registration/tracking in place of the new controller in this series.

Thanks everyone for the feedback.
-T.J.

> > Thanks.
> >
> > --
> > tejun