On Mon, Feb 14, 2022 at 12:37 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Mon, Feb 14, 2022 at 12:19 PM Todd Kjos <tkjos@xxxxxxxxxx> wrote: > > On Mon, Feb 14, 2022 at 11:29 AM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote: > > > On Mon, Feb 14, 2022 at 10:33 AM Todd Kjos <tkjos@xxxxxxxxxx> wrote: > > > > > > > > Since we are creating a new gpu cgroup abstraction, couldn't this > > > > "transfer" be done in userspace by the target instead of in the kernel > > > > driver? Then this patch would reduce to just a flag on the buffer > > > > object. > > > > > > Are you suggesting to have a userspace accessible cgroup interface for > > > transferring buffer charges and the target process to use that > > > interface for requesting the buffer to be charged to its cgroup? > > > > Well, I'm asking why we need to do these cgroup-ish actions in the > > kernel when it seems more natural to do it in userspace. This was our plan originally i.e. to create a cgroup interface that userspace could use for explicit charge transfer. However, in our initial discussions with all interested parties and cgroup maintainers we reached a conclusion that an explicit charge transfer UAPI for the cgroup controller did not fit in with the current cgroup charge/uncharge mechanisms. Like John mentioned, the charge transfer during binder IPC was suggested by Daniel during LPC. Regards, Hridya > > > > In case its useful, some additional context from some of the Linux > Plumber's discussions last fall: > > Daniel Stone outlines some concerns with the cgroup userland handling > for accounting: > https://youtu.be/3OqllZONTiQ?t=3430 > > And the binder ownership transfer bit was suggested here by Daniel Vetter: > https://youtu.be/3OqllZONTiQ?t=3730 > > thanks > -john
