On Mon, Feb 14, 2022 at 12:37 PM John Stultz john.stultz@linaro.org wrote:
On Mon, Feb 14, 2022 at 12:19 PM Todd Kjos tkjos@google.com wrote:
On Mon, Feb 14, 2022 at 11:29 AM Suren Baghdasaryan surenb@google.com wrote:
On Mon, Feb 14, 2022 at 10:33 AM Todd Kjos tkjos@google.com 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