devices to the cgroup subsystem.
In addition to the cgroup_subsys_state that is common to all DRM
devices, a device-specific state is introduced and it is allocated
according to the vendor of the device.
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
include/drm
Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h| 32
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 5
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c | 46
Account for the number of command submitted to amdgpu by type on a per
cgroup basis, for the purpose of profiling/monitoring applications.
x prefix in the control file name x.cmd_submitted.amd.stat signify
experimental.
Change-Id: Ibc22e5bda600f54fe820fe0af5400ca348691550
Signed-off-by: Kenny Ho
Change-Id: Ib66c44ac1b1c367659e362a2fc05b6fbb3805876
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/Makefile | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c | 37 +
drivers/gpu/drm/amd/amdgpu
Account for the total size of buffer object requested to amdgpu by
buffer type on a per cgroup basis.
x prefix in the control file name x.bo_requested.amd.stat signify
experimental.
Change-Id: Ifb680c4bcf3652879a7a659510e25680c2465cf6
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu
/manage-gpus/scheduling-gpus/
[6]
https://blog.openshift.com/gpu-accelerated-sql-queries-with-postgresql-pg-strom-in-openshift-3-10/
[7] https://github.com/RadeonOpenCompute/k8s-device-plugin
[8] https://github.com/kubernetes/kubernetes/issues/52757
Kenny Ho (5):
cgroup: Introduce cgroup for drm
> Count us (Mellanox) too, our RDMA devices are exposing special and
> limited in size device memory to the users and we would like to provide
> an option to use cgroup to control its exposure.
Doesn't RDMA already has a separate cgroup? Why not implement it there?
> > and with future work, we
On Sun, May 5, 2019 at 3:14 AM Leon Romanovsky wrote:
> > > Doesn't RDMA already has a separate cgroup? Why not implement it there?
> > >
> >
> > Hi Kenny, I can't answer for Leon, but I'm hopeful he agrees with rationale
> > I gave in the cover letter. Namely, to implement in rdma controller,
(sent again. Not sure why my previous email was just a reply instead
of reply-all.)
On Sun, May 5, 2019 at 12:05 PM Leon Romanovsky wrote:
> We are talking about two different access patterns for this device
> memory (DM). One is to use this device memory (DM) and second to
> configure/limit.
