[RFC v3 5/8] dmabuf: Add gpu cgroup charge transfer function

Michal Koutný mkoutny at suse.com
Tue Mar 22 09:52:24 UTC 2022


On Mon, Mar 21, 2022 at 04:54:26PM -0700, "T.J. Mercier"
<tjmercier at google.com> wrote:
> Since the charge is duplicated in two cgroups for a short period
> before it is uncharged from the source cgroup I guess the situation
> you're thinking about is a global (or common ancestor) limit?

The common ancestor was on my mind (after the self-shortcut).

> I can see how that would be a problem for transfers done this way and
> an alternative would be to swap the order of the charge operations:
> first uncharge, then try_charge. To be certain the uncharge is
> reversible if the try_charge fails, I think I'd need either a mutex
> used at all gpucg_*charge call sites or access to the gpucg_mutex,

Yes, that'd provide safe conditions for such operations, although I'm
not sure these special types of memory can afford global lock on their
fast paths.

> which implies adding transfer support to gpu.c as part of the gpucg_*
> API itself and calling it here. Am I following correctly here?

My idea was to provide a special API (apart from
gpucp_{try_charge,uncharge}) to facilitate transfers...

> This series doesn't actually add limit support just accounting, but
> I'd like to get it right here.

...which could be implemented (or changed) depending on how the charging
is realized internally.


Michal


More information about the dri-devel mailing list