From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
To: Kenny Ho <Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
Cc: jsparks-WVYJKLFxKCc@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
lkaplan-WVYJKLFxKCc@public.gmane.org,
alexander.deucher-5C7GfCeVMHo@public.gmane.org,
y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
joseph.greathouse-5C7GfCeVMHo@public.gmane.org,
tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
christian.koenig-5C7GfCeVMHo@public.gmane.org
Subject: Re: [RFC PATCH v3 02/11] cgroup: Add mechanism to register DRM devices
Date: Wed, 26 Jun 2019 17:56:05 +0200 [thread overview]
Message-ID: <20190626155605.GQ12905@phenom.ffwll.local> (raw)
In-Reply-To: <20190626150522.11618-3-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
On Wed, Jun 26, 2019 at 11:05:13AM -0400, Kenny Ho wrote:
> Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
> Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
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 the basic GEM stuff would be set up
automically (there's really no reason not to I think).
Also tying to the minor is a bit funky, since we have multiple of these.
Need to make sure were at least consistent with whether we use the primary
or render minor - I'd always go with the primary one like you do here.
> ---
> 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 include/drm/drm_cgroup.h
>
> diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
> new file mode 100644
> index 000000000000..ddb9eab64360
> --- /dev/null
> +++ b/include/drm/drm_cgroup.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: MIT
> + * Copyright 2019 Advanced Micro Devices, Inc.
> + */
> +#ifndef __DRM_CGROUP_H__
> +#define __DRM_CGROUP_H__
> +
> +#ifdef CONFIG_CGROUP_DRM
> +
> +int drmcgrp_register_device(struct drm_device *device);
> +
> +int drmcgrp_unregister_device(struct drm_device *device);
> +
> +#else
> +static inline int drmcgrp_register_device(struct drm_device *device)
> +{
> + return 0;
> +}
> +
> +static inline int drmcgrp_unregister_device(struct drm_device *device)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_CGROUP_DRM */
> +#endif /* __DRM_CGROUP_H__ */
> diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
> index 9928e60037a5..27497f786c93 100644
> --- a/include/linux/cgroup_drm.h
> +++ b/include/linux/cgroup_drm.h
> @@ -6,10 +6,20 @@
>
> #ifdef CONFIG_CGROUP_DRM
>
> +#include <linux/mutex.h>
> #include <linux/cgroup.h>
> +#include <drm/drm_file.h>
> +
> +/* limit defined per the way drm_minor_alloc operates */
> +#define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
> +
> +struct drmcgrp_device_resource {
> + /* for per device stats */
> +};
>
> struct drmcgrp {
> struct cgroup_subsys_state css;
> + struct drmcgrp_device_resource *dev_resources[MAX_DRM_DEV];
> };
>
> static inline struct drmcgrp *css_drmcgrp(struct cgroup_subsys_state *css)
> diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
> index 66cb1dda023d..7da6e0d93991 100644
> --- a/kernel/cgroup/drm.c
> +++ b/kernel/cgroup/drm.c
> @@ -1,28 +1,99 @@
> // SPDX-License-Identifier: MIT
> // Copyright 2019 Advanced Micro Devices, Inc.
> +#include <linux/export.h>
> #include <linux/slab.h>
> #include <linux/cgroup.h>
> +#include <linux/fs.h>
> +#include <linux/seq_file.h>
> +#include <linux/mutex.h>
> #include <linux/cgroup_drm.h>
> +#include <linux/kernel.h>
> +#include <drm/drm_device.h>
> +#include <drm/drm_cgroup.h>
> +
> +static DEFINE_MUTEX(drmcgrp_mutex);
> +
> +struct drmcgrp_device {
> + struct drm_device *dev;
> + struct mutex mutex;
> +};
> +
> +/* indexed by drm_minor for access speed */
> +static struct drmcgrp_device *known_drmcgrp_devs[MAX_DRM_DEV];
> +
> +static int max_minor;
Uh no global stuff like this please. Or some explanation in the commit
message why we really cant avoid this.
> +
>
> static struct drmcgrp *root_drmcgrp __read_mostly;
>
> static void drmcgrp_css_free(struct cgroup_subsys_state *css)
> {
> struct drmcgrp *drmcgrp = css_drmcgrp(css);
> + int i;
> +
> + for (i = 0; i <= max_minor; i++) {
> + if (drmcgrp->dev_resources[i] != NULL)
> + kfree(drmcgrp->dev_resources[i]);
> + }
>
> kfree(drmcgrp);
> }
>
> +static inline int init_drmcgrp_single(struct drmcgrp *drmcgrp, int minor)
> +{
> + struct drmcgrp_device_resource *ddr = drmcgrp->dev_resources[minor];
> +
> + if (ddr == NULL) {
> + ddr = kzalloc(sizeof(struct drmcgrp_device_resource),
> + GFP_KERNEL);
> +
> + if (!ddr)
> + return -ENOMEM;
> +
> + drmcgrp->dev_resources[minor] = ddr;
> + }
> +
> + /* set defaults here */
> +
> + return 0;
> +}
> +
> +static inline int init_drmcgrp(struct drmcgrp *drmcgrp, struct drm_device *dev)
> +{
> + int rc = 0;
> + int i;
> +
> + if (dev != NULL) {
> + rc = init_drmcgrp_single(drmcgrp, dev->primary->index);
> + return rc;
> + }
> +
> + for (i = 0; i <= max_minor; i++) {
> + rc = init_drmcgrp_single(drmcgrp, i);
> + if (rc)
> + return rc;
> + }
> +
> + return 0;
> +}
> +
> static struct cgroup_subsys_state *
> drmcgrp_css_alloc(struct cgroup_subsys_state *parent_css)
> {
> struct drmcgrp *parent = css_drmcgrp(parent_css);
> struct drmcgrp *drmcgrp;
> + int rc;
>
> drmcgrp = kzalloc(sizeof(struct drmcgrp), GFP_KERNEL);
> if (!drmcgrp)
> return ERR_PTR(-ENOMEM);
>
> + rc = init_drmcgrp(drmcgrp, NULL);
> + if (rc) {
> + drmcgrp_css_free(&drmcgrp->css);
> + return ERR_PTR(rc);
> + }
> +
> if (!parent)
> root_drmcgrp = drmcgrp;
>
> @@ -40,3 +111,48 @@ struct cgroup_subsys drm_cgrp_subsys = {
> .legacy_cftypes = files,
> .dfl_cftypes = files,
> };
> +
> +int drmcgrp_register_device(struct drm_device *dev)
Imo this should be done as part of drm_dev_register (maybe only if the
driver has set up a controller or something). Definitely with the
unregister logic below. Also anything used by drivers needs kerneldoc.
> +{
> + struct drmcgrp_device *ddev;
> +
> + ddev = kzalloc(sizeof(struct drmcgrp_device), GFP_KERNEL);
> + if (!ddev)
> + return -ENOMEM;
> +
> + ddev->dev = dev;
> + mutex_init(&ddev->mutex);
> +
> + mutex_lock(&drmcgrp_mutex);
> + known_drmcgrp_devs[dev->primary->index] = ddev;
> + max_minor = max(max_minor, dev->primary->index);
> + mutex_unlock(&drmcgrp_mutex);
> +
> + /* init cgroups created before registration (i.e. root cgroup) */
> + if (root_drmcgrp != NULL) {
> + struct cgroup_subsys_state *pos;
> + struct drmcgrp *child;
> +
> + rcu_read_lock();
> + css_for_each_descendant_pre(pos, &root_drmcgrp->css) {
> + child = css_drmcgrp(pos);
> + init_drmcgrp(child, dev);
> + }
> + rcu_read_unlock();
I have no idea, but is this guaranteed to get them all?
-Daniel
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drmcgrp_register_device);
> +
> +int drmcgrp_unregister_device(struct drm_device *dev)
> +{
> + mutex_lock(&drmcgrp_mutex);
> +
> + kfree(known_drmcgrp_devs[dev->primary->index]);
> + known_drmcgrp_devs[dev->primary->index] = NULL;
> +
> + mutex_unlock(&drmcgrp_mutex);
> + return 0;
> +}
> +EXPORT_SYMBOL(drmcgrp_unregister_device);
> --
> 2.21.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-06-26 15:56 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 15:05 [RFC PATCH v3 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
2019-06-26 15:05 ` [RFC PATCH v3 02/11] cgroup: Add mechanism to register DRM devices Kenny Ho
[not found] ` <20190626150522.11618-3-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-06-26 15:56 ` Daniel Vetter [this message]
2019-06-26 20:37 ` Kenny Ho
2019-06-26 21:03 ` Daniel Vetter
[not found] ` <CAKMK7uERvn7Ed2trGQShM94Ozp6+x8bsULFyGj9CYWstuzb56A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-26 21:58 ` Kenny Ho
2019-06-26 15:05 ` [RFC PATCH v3 03/11] drm/amdgpu: Register AMD devices for DRM cgroup Kenny Ho
2019-06-26 15:05 ` [RFC PATCH v3 04/11] drm, cgroup: Add total GEM buffer allocation limit Kenny Ho
[not found] ` <20190626150522.11618-5-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-06-26 16:05 ` Daniel Vetter
[not found] ` <20190626160553.GR12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-26 21:27 ` Kenny Ho
[not found] ` <CAOWid-eurCMx1F7ciUwx0e+p=s=NP8=UxQUhhF-hdK-iAna+fA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-26 21:41 ` Daniel Vetter
[not found] ` <20190626214113.GA12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-26 22:41 ` Kenny Ho
[not found] ` <CAOWid-egYGijS0a6uuG4mPUmOWaPwF-EKokR=LFNJ=5M+akVZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-27 5:43 ` Daniel Vetter
2019-06-27 18:42 ` Kenny Ho
[not found] ` <CAOWid-cT4TQ7HGzcSWjmLGjAW_D1hRrkNguEiV8N+baNiKQm_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-27 21:24 ` Daniel Vetter
2019-06-28 18:43 ` Kenny Ho
[not found] ` <CAOWid-dZQhpKHxYEFn+X+WSep+B66M_LtN6v0=4-uO3ecZ0pcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-07-02 13:16 ` Daniel Vetter
2019-06-26 15:05 ` [RFC PATCH v3 07/11] drm, cgroup: Add TTM buffer allocation stats Kenny Ho
2019-06-26 16:12 ` Daniel Vetter
[not found] ` <20190626161254.GS12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-27 4:06 ` Kenny Ho
[not found] ` <CAOWid-f3kKnM=4oC5Bba5WW5WNV2MH5PvVamrhO6LBr5ydPJQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-27 6:01 ` Daniel Vetter
2019-06-27 20:17 ` Kenny Ho
2019-06-27 21:33 ` Daniel Vetter
2019-06-28 1:16 ` Welty, Brian
[not found] ` <01a6efa8-802c-b8b1-931e-4f0c1c63beca-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-06-28 6:53 ` Daniel Vetter
2019-06-26 15:05 ` [RFC PATCH v3 08/11] drm, cgroup: Add TTM buffer peak usage stats Kenny Ho
2019-06-26 16:16 ` Daniel Vetter
2019-06-26 15:05 ` [RFC PATCH v3 10/11] drm, cgroup: Add soft VRAM limit Kenny Ho
[not found] ` <20190626150522.11618-1-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-06-26 15:05 ` [RFC PATCH v3 01/11] cgroup: Introduce cgroup for drm subsystem Kenny Ho
[not found] ` <20190626150522.11618-2-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-06-26 15:49 ` Daniel Vetter
2019-06-26 19:35 ` Kenny Ho
[not found] ` <CAOWid-dyGwf=e0ikBEQ=bnVM_bC8-FeTOD8fJVMJKUgPv6vtyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-26 20:12 ` Daniel Vetter
2019-06-26 15:05 ` [RFC PATCH v3 05/11] drm, cgroup: Add peak GEM buffer allocation limit Kenny Ho
2019-06-26 15:05 ` [RFC PATCH v3 06/11] drm, cgroup: Add GEM buffer allocation count stats Kenny Ho
2019-06-26 15:05 ` [RFC PATCH v3 09/11] drm, cgroup: Add per cgroup bw measure and control Kenny Ho
[not found] ` <20190626150522.11618-10-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-06-26 16:25 ` Daniel Vetter
[not found] ` <20190626162554.GU12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-27 4:34 ` Kenny Ho
[not found] ` <CAOWid-dO5QH4wLyN_ztMaoZtLM9yzw-FEMgk3ufbh1ahHJ2vVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-27 6:11 ` Daniel Vetter
[not found] ` <20190627061153.GD12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-06-28 19:49 ` Kenny Ho
[not found] ` <CAOWid-dCkevUiN27pkwfPketdqS8O+ZGYu8vRMPY2GhXGaVARA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-07-02 13:20 ` Daniel Vetter
2019-06-26 15:05 ` [RFC PATCH v3 11/11] drm, cgroup: Allow more aggressive memory reclaim Kenny Ho
[not found] ` <20190626150522.11618-12-Kenny.Ho-5C7GfCeVMHo@public.gmane.org>
2019-06-26 16:44 ` Daniel Vetter
2019-06-26 22:52 ` Kenny Ho
2019-06-27 6:15 ` Daniel Vetter
2019-06-27 7:24 ` [RFC PATCH v3 00/11] new cgroup controller for gpu/drm subsystem Daniel Vetter
2019-06-30 5:10 ` Kenny Ho
2019-07-02 13:21 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190626155605.GQ12905@phenom.ffwll.local \
--to=daniel-/w4ywyx8dfk@public.gmane.org \
--cc=Kenny.Ho-5C7GfCeVMHo@public.gmane.org \
--cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=joseph.greathouse-5C7GfCeVMHo@public.gmane.org \
--cc=jsparks-WVYJKLFxKCc@public.gmane.org \
--cc=lkaplan-WVYJKLFxKCc@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox