On Mon, Mar 21, 2022 at 04:54:26PM -0700, "T.J. Mercier" tjmercier@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