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
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
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
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
/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
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
Hey Christian,
Sorry for the late reply, I missed this for some reason.
On Wed, Nov 21, 2018 at 5:00 AM Christian König
wrote:
> > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> > index 370e9a5536ef..531726443104 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> >
Ah I see. Thank you for the clarification.
Regards,
Kenny
On Tue, Nov 27, 2018 at 3:31 PM Christian König
wrote:
>
> Am 27.11.18 um 19:15 schrieb Kenny Ho:
> > Hey Christian,
> >
> > Sorry for the late reply, I missed this for some reason.
> >
> > On Wed, Nov
On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
> On 5/9/2019 2:04 PM, Kenny Ho wrote:
> > There are four control file types,
> > stats (ro) - display current measured values for a resource
> > max (rw) - limits for a resource
> > default (ro, root cgroup only) - de
On Fri, May 10, 2019 at 1:48 PM Koenig, Christian
wrote:
> Well another question is why do we want to prevent that in the first place?
>
> I mean the worst thing that can happen is that we account a BO multiple
> times.
That's one of the problems. The other one is the BO outliving the
lifetime
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
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
include/drm/drm_cgroup.h | 24
include/linux/cgroup_drm.h | 10
kernel/cgroup/drm.c| 118 -
3 files changed, 151 insertions(+), 1 deletion(-)
create
Change-Id: I3750fc657b956b52750a36cb303c54fa6a265b44
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index da7b4fe8ade3..2568fd730161
This new drmcgrp resource limits the largest GEM buffer that can be
allocated in a cgroup.
Change-Id: I0830d56775568e1cf215b56cc892d5e7945e9f25
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h | 2 ++
kernel/cgroup/drm.c| 59 ++
2 files changed
-i '1s/.*/536870912/' /sys/fs/cgroup//drm.buffer.total.max
Change-Id: I4c249d06d45ec709d6481d4cbe87c5168545c5d0
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +
drivers/gpu/drm/drm_gem.c | 7 +
drivers/gpu/drm/drm_prime.c| 9
://github.com/RadeonOpenCompute/k8s-device-plugin
[8] https://github.com/kubernetes/kubernetes/issues/52757
Kenny Ho (5):
cgroup: Introduce cgroup for drm subsystem
cgroup: Add mechanism to register DRM devices
drm/amdgpu: Register AMD devices for DRM cgroup
drm, cgroup: Add total GEM
On Fri, May 10, 2019 at 8:28 AM Christian König
wrote:
>
> Am 09.05.19 um 23:04 schrieb Kenny Ho:
> > + /* only allow bo from the same cgroup or its ancestor to be imported
> > */
> > + if (drmcgrp != NULL &&
> > + !drmcgrp_is_
On Fri, May 10, 2019 at 11:08 AM Koenig, Christian
wrote:
> Am 10.05.19 um 16:57 schrieb Kenny Ho:
> > On Fri, May 10, 2019 at 8:28 AM Christian König
> > wrote:
> >> Am 09.05.19 um 23:04 schrieb Kenny Ho:
> So the drm cgroup container is separate to other cgroup cont
lement? I would be happy to dig into those.
Regards,
Kenny
> The only major issue I can see is on patch #4, see there for further
> details.
>
> Christian.
>
> Am 09.05.19 um 23:04 schrieb Kenny Ho:
> > This is a follow up to the RFC I made last november to introduce a cgrou
On Thu, May 16, 2019 at 3:25 AM Christian König
wrote:
> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> > Am 16.05.19 um 04:29 schrieb Kenny Ho:
> >> On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
> >>> On 5/9/2019 2:04 PM, Kenny Ho wrote:
> >>>
On Thu, May 16, 2019 at 10:12 AM Christian König
wrote:
> Am 16.05.19 um 16:03 schrieb Kenny Ho:
> > On Thu, May 16, 2019 at 3:25 AM Christian König
> > wrote:
> >> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> >> We need something like the Linux
On Thu, May 16, 2019 at 10:10 AM Tejun Heo wrote:
> I haven't gone through the patchset yet but some quick comments.
>
> On Wed, May 15, 2019 at 10:29:21PM -0400, Kenny Ho wrote:
> > Given this controller is specific to the drm kernel subsystem which
> > uses minor to identif
> 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.
On Thu, Jun 27, 2019 at 2:01 AM Daniel Vetter wrote:
>
> btw reminds me: I guess it would be good to have a per-type .total
> read-only exposed, so that userspace has an idea of how much there is?
> ttm is trying to be agnostic to the allocator that's used to manage a
> memory type/resource, so
On Thu, Jun 27, 2019 at 1:43 AM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 06:41:32PM -0400, Kenny Ho wrote:
> > So without the sharing restriction and some kind of ownership
> > structure, we will have to migrate/change the owner of the buffer when
> > the cgroup
Change-Id: I3750fc657b956b52750a36cb303c54fa6a265b44
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index da7b4fe8ade3..2568fd730161
-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 (11):
cgroup: Introduce cgroup for drm subsystem
cgroup: Add mechanism to register DRM devices
drm/amdgpu: Register AMD
Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h| 76 +++
include/linux/cgroup_subsys.h | 4 ++
init/Kconfig | 5 +++
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
drm.buffer.count.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of GEM buffer allocated.
Change-Id: Id3e1809d5fee8562e47a7d2b961688956d844ec6
Signed-off-by: Kenny Ho
---
include/linux
echo "226:0 512m" > drm.buffer.total.max
Change-Id: I4c249d06d45ec709d6481d4cbe87c5168545c5d0
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +
drivers/gpu/drm/drm_gem.c | 8 +
drivers/gpu/drm/drm_prime.c| 9 +
"226:1 4m" > drm.buffer.peak.max
Change-Id: I0830d56775568e1cf215b56cc892d5e7945e9f25
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h | 3 ++
kernel/cgroup/drm.c| 61 ++
2 files changed, 64 insertions(+)
diff --git a/include/linux
=9223372036854775807 avg_bytes_per_us=65536
Change-Id: Ie573491325ccc16535bb943e7857f43bd0962add
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +
include/drm/drm_cgroup.h | 13 ++
include/linux/cgroup_drm.h | 14 ++
kernel/cgroup/drm.c | 309 ++-
4
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of evictions.
Change-Id: Ice2c4cc845051229549bebeb6aa2d7d6153bdf6a
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +-
drivers/gpu
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
include/drm/drm_cgroup.h | 24
include/linux/cgroup_drm.h | 10
kernel/cgroup/drm.c| 116 +
3 files changed, 150 insertions(+)
create mode 100644
== ==
Reading returns the following::
226:0 system=0 tt=0 vram=0 priv=0
226:1 system=0 tt=9035776 vram=17768448 priv=16809984
226:2 system=0 tt=9035776 vram=17768448 priv=16809984
Change-Id: I986e44533848f66411465bdd52105e78105a709a
Signed-off-by: Kenny Ho
---
include
Allow DRM TTM memory manager to register a work_struct, such that, when
a drmcgrp is under memory pressure, memory reclaiming can be triggered
immediately.
Change-Id: I25ac04e2db9c19ff12652b88ebff18b44b2706d8
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c| 47
: I7988e28a453b53140b40a28c176239acbc81d491
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ++
include/drm/drm_cgroup.h | 15
include/linux/cgroup_drm.h | 2 +
kernel/cgroup/drm.c | 145 +++
4 files changed, 169 insertions
On Wed, Jun 26, 2019 at 11:49 AM Daniel Vetter wrote:
>
> Bunch of naming bikesheds
I appreciate the suggestions, naming is hard :).
> > +#include
> > +
> > +struct drmcgrp {
>
> drm_cgroup for more consistency how we usually call these things.
I was hoping to keep the symbol short if
On Wed, Jun 26, 2019 at 12:05 PM Daniel Vetter wrote:
>
> > drm.buffer.default
> > A read-only flat-keyed file which exists on the root cgroup.
> > Each entry is keyed by the drm device's major:minor.
> >
> > Default limits on the total GEM buffer allocation in bytes.
>
>
(sending again, I keep missing the reply-all in gmail.)
On Wed, Jun 26, 2019 at 11:56 AM Daniel Vetter wrote:
>
> Why the separate, explicit registration step? I think a simpler design for
> drivers would be that we set up cgroups if there's anything to be
> controlled, and then for GEM drivers
On Wed, Jun 26, 2019 at 5:04 PM Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 10:37 PM Kenny Ho wrote:
> > (sending again, I keep missing the reply-all in gmail.)
> You can make it the default somewhere in the gmail options.
Um... interesting, my option was actually not set (n
On Thu, Jun 27, 2019 at 3:24 AM Daniel Vetter wrote:
> Another question I have: What about HMM? With the device memory zone
> the core mm will be a lot more involved in managing that, but I also
> expect that we'll have classic buffer-based management for a long time
> still. So these need to
On Wed, Jun 26, 2019 at 12:12 PM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 11:05:18AM -0400, Kenny Ho wrote:
> > drm.memory.stats
> > A read-only nested-keyed file which exists on all cgroups.
> > Each entry is keyed by the
On Wed, Jun 26, 2019 at 12:25 PM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 11:05:20AM -0400, Kenny Ho wrote:
> > The bandwidth is measured by keeping track of the amount of bytes moved
> > by ttm within a time period. We defined two type of bandwidth: burst
> &g
On Wed, Jun 26, 2019 at 5:41 PM Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 05:27:48PM -0400, Kenny Ho wrote:
> > On Wed, Jun 26, 2019 at 12:05 PM Daniel Vetter wrote:
> > > So what happens when you start a lot of threads all at the same time,
> > > allocating gem b
11:05:22AM -0400, Kenny Ho wrote:
> > Allow DRM TTM memory manager to register a work_struct, such that, when
> > a drmcgrp is under memory pressure, memory reclaiming can be triggered
> > immediately.
> >
> > Change-Id: I25ac04e2db9c19ff12652b88ebff18b4
On Thu, Jun 27, 2019 at 2:11 AM Daniel Vetter wrote:
> I feel like a better approach would by to add a cgroup for the various
> engines on the gpu, and then also account all the sdma (or whatever the
> name of the amd copy engines is again) usage by ttm_bo moves to the right
> cgroup. I think
On Thu, Jun 27, 2019 at 5:24 PM Daniel Vetter wrote:
> On Thu, Jun 27, 2019 at 02:42:43PM -0400, Kenny Ho wrote:
> > Um... I am going to get a bit philosophical here and suggest that the
> > idea of sharing (especially uncontrolled sharing) is inherently at odd
> > with co
Hi Tejun,
Thanks for looking into this. I can definitely help where I can and I
am sure other experts will jump in if I start misrepresenting the
reality :) (as Daniel already have done.)
Regarding your points, my understanding is that there isn't really a
TTM vs GEM situation anymore (there is
On Tue, Sep 3, 2019 at 5:20 AM Daniel Vetter wrote:
>
> On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian
> wrote:
> >
> > Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> > > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> > >> With this
On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
>
> On Thu, Aug 29, 2019 at 02:05:18AM -0400, Kenny Ho wrote:
> > To allow other subsystems to iterate through all stored DRM minors and
> > act upon them.
> >
> > Also exposes drm_minor_acquire and drm_min
On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> > > Iterating over minors for cgroups sounds very, very wrong. Why do we care
> > > whether a buffer was al
straightforward as far as I understand it currently.)
Regards,
Kenny
On Thu, Aug 29, 2019 at 3:08 AM Koenig, Christian
wrote:
> Am 29.08.19 um 08:05 schrieb Kenny Ho:
> > Allow DRM TTM memory manager to register a work_struct, such that, when
> > a drmcgrp is under memory pressure, memory
istinction which domain you need to evict stuff from.
>
> Regards,
> Christian.
>
> Am 29.08.19 um 16:07 schrieb Kenny Ho:
>
> Thanks for the feedback Christian. I am still digging into this one. Daniel
> suggested leveraging the Shrinker API for the functionality of th
: I7c4b67ce6b31f06d1037b03435386ff5b8144ca5
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/drm_drv.c | 19 +++
drivers/gpu/drm/drm_internal.h | 4
include/drm/drm_drv.h | 4
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index
/kubernetes/kubernetes/issues/52757
Kenny Ho (16):
drm: Add drm_minor_for_each
cgroup: Introduce cgroup for drm subsystem
drm, cgroup: Initialize drmcg properties
drm, cgroup: Add total GEM buffer allocation stats
drm, cgroup: Add peak GEM buffer allocation stats
drm, cgroup: Add GEM buffer
by the drm device's major:minor.
Total GEM buffer allocation in bytes.
Change-Id: I9d662ec50d64bb40a37dbf47f018b2f3a1c033ad
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 50 +-
drivers/gpu/drm/drm_gem.c | 9 ++
include/drm/drm_cgroup.h
virtualization.)
Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 18 -
Documentation/cgroup-v1/drm.rst | 1 +
include/linux/cgroup_drm.h | 92 +
include/linux/cgroup_subsys.h
: I7988e28a453b53140b40a28c176239acbc81d491
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ++
include/drm/drm_cgroup.h | 17 +
include/linux/cgroup_drm.h | 2 +
kernel/cgroup/drm.c | 135 +++
4 files changed, 161 insertions
(such as k, m, g) can be used.
Set largest allocation for /dev/dri/card1 to 4MB
echo "226:1 4m" > drm.buffer.peak.max
Change-Id: I0830d56775568e1cf215b56cc892d5e7945e9f25
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 18 ++
to the root cgroup since it can be
created before DRM devices are available. The drmcg controller will go
through all existing drm cgroups and initialize them with the new device
accordingly.
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
drivers/gpu/drm
drm.buffer.count.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of GEM buffer allocated.
Change-Id: Id3e1809d5fee8562e47a7d2b961688956d844ec6
Signed-off-by: Kenny Ho
---
Documentation
=9223372036854775807 avg_bytes_per_us=65536
Change-Id: Ie573491325ccc16535bb943e7857f43bd0962add
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +
include/drm/drm_cgroup.h | 19 +++
include/linux/cgroup_drm.h | 16 ++
kernel/cgroup/drm.c | 319 ++-
4
its
in list will be ignored.
This lgpu resource supports the 'allocation' resource
distribution model.
Change-Id: I1afcacf356770930c7f925df043e51ad06ceb98e
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 46
include/drm/drm_cgrou
drm.buffer.peak.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Largest (high water mark) GEM buffer allocated in bytes.
Change-Id: I79e56222151a3d33a76a61ba0097fe93ebb3449f
Signed-off-by: Kenny Ho
== ==
Reading returns the following::
226:0 system=0 tt=0 vram=0 priv=0
226:1 system=0 tt=9035776 vram=17768448 priv=16809984
226:2 system=0 tt=9035776 vram=17768448 priv=16809984
Change-Id: I986e44533848f66411465bdd52105e78105a709a
Signed-off-by: Kenny Ho
---
include
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of evictions.
Change-Id: Ice2c4cc845051229549bebeb6aa2d7d6153bdf6a
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +-
drivers/gpu
allocation limit for /dev/dri/card1 to 1GB
echo "226:1 1g" > drm.buffer.total.max
Set allocation limit for /dev/dri/card0 to 512MB
echo "226:0 512m" > drm.buffer.total.max
Change-Id: I96e0b7add4d331ed8bb267b3c9243d360c6e9903
Signed-off-by: Kenny Ho
---
Allow DRM TTM memory manager to register a work_struct, such that, when
a drmcgrp is under memory pressure, memory reclaiming can be triggered
immediately.
Change-Id: I25ac04e2db9c19ff12652b88ebff18b44b2706d8
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c| 49
type for the migrated task.
Change-Id: I68187a72818b855b5f295aefcb241cda8ab63b00
Signed-off-by: Kenny Ho
---
include/drm/drm_drv.h | 10
kernel/cgroup/drm.c | 57 +++
2 files changed, 67 insertions(+)
diff --git a/include/drm/drm_drv.h b/include
by the drmcg the kfd process belongs to.
Change-Id: I69a57452c549173a1cd623c30dc57195b3b6563e
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 21 +++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 6 +
drivers/gpu
On Thu, Sep 5, 2019 at 4:06 PM Daniel Vetter wrote:
>
> On Thu, Sep 5, 2019 at 8:28 PM Kenny Ho wrote:
> >
> > (resent in plain text mode)
> >
> > Hi Daniel,
> >
> > This is the previous patch relevant to this discussion:
> > https://patchwork.
2019 at 04:43:45PM -0400, Kenny Ho wrote:
> > On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> > > On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > > > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter
> wrote:
> > > > > Iterating over mi
ter wrote:
>
> On Tue, Sep 03, 2019 at 04:43:45PM -0400, Kenny Ho wrote:
> > On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> > > On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > > > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> > > > >
On Thu, Sep 5, 2019 at 4:32 PM Daniel Vetter wrote:
>
*snip*
> drm_dev_unregister gets called on hotunplug, so your cgroup-internal
> tracking won't get out of sync any more than the drm_minor list gets
> out of sync with drm_devices. The trouble with drm_minor is just that
> cgroup doesn't track
ussion to me or
> have me cc'ed in that thread?
>
> Best,
> Yiwei
>
> On Wed, Oct 30, 2019 at 10:23 PM Kenny Ho wrote:
>>
>> Hi Yiwei,
>>
>> I am not sure if you are aware, there is an ongoing RFC on adding drm
>> support in cgroup for the purpose of res
Hi Yiwei,
I am not sure if you are aware, there is an ongoing RFC on adding drm
support in cgroup for the purpose of resource tracking. One of the
resource is GPU memory. It's not exactly the same as what you are
proposing (it doesn't track API usage, but it tracks the type of GPU
memory from
On Tue, Oct 1, 2019 at 10:31 AM Michal Koutný wrote:
> On Thu, Aug 29, 2019 at 02:05:19AM -0400, Kenny Ho wrote:
> > +struct cgroup_subsys drm_cgrp_subsys = {
> > + .css_alloc = drmcg_css_alloc,
> > + .css_free = drmcg_css_free,
> > +
On Tue, Oct 1, 2019 at 10:30 AM Michal Koutný wrote:
> On Thu, Aug 29, 2019 at 02:05:24AM -0400, Kenny Ho wrote:
> > drm.buffer.default
> > A read-only flat-keyed file which exists on the root cgroup.
> > Each entry is keyed by the drm
:
> > On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> > > drm.lgpu
> > > A read-write nested-keyed file which exists on all cgroups.
> > > Each entry is keyed by the DRM device's major:minor.
> > >
> > > lgpu stands for
by the drm device's major:minor.
Total GEM buffer allocation in bytes.
Change-Id: Ibc1f646ca7dbc588e2d11802b156b524696a23e7
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 50 +-
drivers/gpu/drm/drm_gem.c | 9 ++
include/drm/drm_cgroup.h
gpu.buffer.peak.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Largest (high water mark) GEM buffer allocated in bytes.
Change-Id: I40fe4c13c1cea8613b3e04b802f3e1f19eaab4fc
Signed-off-by: Kenny Ho
applies to the root cgroup since it can be
created before DRM devices are available. The drmcg controller will go
through all existing drm cgroups and initialize them with the new device
accordingly.
Change-Id: I64e421d8dfcc22ee8282cc1305960e20c2704db7
Signed-off-by: Kenny Ho
---
drivers/gpu/drm
Since the drm subsystem can be compiled as a module and drm devices can
be added and removed during run time, add several functions to bind the
drm subsystem as well as drm devices with drmcg.
Two pairs of functions:
drmcg_bind/drmcg_unbind - used to bind/unbind the drm subsystem to the
cgroup
allocation limit for /dev/dri/card1 to 1GB
echo "226:1 1g" > gpu.buffer.total.max
Set allocation limit for /dev/dri/card0 to 512MB
echo "226:0 512m" > gpu.buffer.total.max
Change-Id: Id3265bbd0fafe84a16b59617df79bd32196160be
Signed-off-by: Kenny Ho
---
(such as k, m, g) can be used.
Set largest allocation for /dev/dri/card1 to 4MB
echo "226:1 4m" > gpu.buffer.peak.max
Change-Id: I5ab3fb4a442b6cbd5db346be595897c90217da69
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 18 +++
Enumeration of the subdevices
= ==
Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 21 +++
include/drm/drm_cgroup.h| 3 +
include/linux/cgroup_drm.h
type for the migrated task.
Change-Id: I0ce7c4e5a04c31bd0f8d9853a383575d4bc9a3fa
Signed-off-by: Kenny Ho
---
include/drm/drm_drv.h | 10
kernel/cgroup/drm.c | 58 +++
2 files changed, 68 insertions(+)
diff --git a/include/drm/drm_drv.h b/include
] https://github.com/kubernetes/kubernetes/issues/52757
Kenny Ho (11):
cgroup: Introduce cgroup for drm subsystem
drm, cgroup: Bind drm and cgroup subsystem
drm, cgroup: Initialize drmcg properties
drm, cgroup: Add total GEM buffer allocation stats
drm, cgroup: Add peak GEM buffer
gpu.buffer.count.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of GEM buffer allocated.
Change-Id: Iad29bdf44390dbcee07b1e72ea0ff811aa3b9dcd
Signed-off-by: Kenny Ho
---
Documentation
virtualization.)
Change-Id: Ia90aed8c4cb89ff20d8216a903a765655b44fc9a
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 18 -
Documentation/cgroup-v1/drm.rst | 1 +
include/linux/cgroup_drm.h | 92 +
include/linux/cgroup_subsys.h
as defined by the drmcg the kfd process belongs to.
Change-Id: I2930e76ef9ac6d36d0feb81f604c89a4208e6614
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 29
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 7
On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote:
>
> Yes, I'd go with absolute units when it comes to memory, because it's
> not a renewable resource like CPU and IO, and so we do have cliff
> behavior around the edge where you transition from ok to not-enough.
>
> memory.low is a bit in
Thanks, I will take a look.
Regards,
Kenny
On Wed, Feb 19, 2020 at 1:38 PM Johannes Weiner wrote:
>
> On Wed, Feb 19, 2020 at 11:28:48AM -0500, Kenny Ho wrote:
> > On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote:
> > >
> > > Yes, I'd go with absolute
he documentation in this patch: "Some DRM
> > devices may only support lgpu as anonymous resources. In such case,
> > the significance of the position of the set bits in list will be
> > ignored." What Intel does with the user expressed configuration of &qu
e user expressed configuration of "5
out of 100" is entirely up to Intel (time slice if you like, change to
specific EUs later if you like, or make it driver configurable to
support both if you like.)
Regards,
Kenny
>
> On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote:
>>
Hi Tejun,
On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo wrote:
>
> I have to agree with Daniel here. My apologies if I weren't clear
> enough. Here's one interface I can think of:
>
> * compute weight: The same format as io.weight. Proportional control
>of gpu compute.
>
> * memory low: Please
by the drm device's major:minor.
Total GEM buffer allocation in bytes.
Change-Id: Ibc1f646ca7dbc588e2d11802b156b524696a23e7
Signed-off-by: Kenny Ho
---
Documentation/admin-guide/cgroup-v2.rst | 50 +-
drivers/gpu/drm/drm_gem.c | 9 ++
include/drm/drm_cgroup.h
1 - 100 of 126 matches
Mail list logo
