* [PATCH v2 01/11] cgroup: Introduce cgroup for drm subsystem
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 02/11] drm, cgroup: Bind drm and cgroup subsystem Kenny Ho
` (10 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
With the increased importance of machine learning, data science and
other cloud-based applications, GPUs are already in production use in
data centers today. Existing GPU resource management is very coarse
grain, however, as sysadmins are only able to distribute workload on a
per-GPU basis. An alternative is to use GPU virtualization (with or
without SRIOV) but it generally acts on the entire GPU instead of the
specific resources in a GPU. With a drm cgroup controller, we can
enable alternate, fine-grain, sub-GPU resource management (in addition
to what may be available via GPU virtualization.)
Change-Id: Ia90aed8c4cb89ff20d8216a903a765655b44fc9a
Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 18 ++++-
Documentation/cgroup-v1/drm.rst | 1 +
include/linux/cgroup_drm.h | 92 +++++++++++++++++++++++++
include/linux/cgroup_subsys.h | 4 ++
init/Kconfig | 5 ++
kernel/cgroup/Makefile | 1 +
kernel/cgroup/drm.c | 42 +++++++++++
7 files changed, 161 insertions(+), 2 deletions(-)
create mode 100644 Documentation/cgroup-v1/drm.rst
create mode 100644 include/linux/cgroup_drm.h
create mode 100644 kernel/cgroup/drm.c
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 0636bcb60b5a..7deff912185e 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -61,8 +61,10 @@ v1 is available under Documentation/admin-guide/cgroup-v1/.
5-6. Device
5-7. RDMA
5-7-1. RDMA Interface Files
- 5-8. Misc
- 5-8-1. perf_event
+ 5-8. GPU
+ 5-8-1. GPU Interface Files
+ 5-9. Misc
+ 5-9-1. perf_event
5-N. Non-normative information
5-N-1. CPU controller root cgroup process behaviour
5-N-2. IO controller root cgroup process behaviour
@@ -2057,6 +2059,18 @@ RDMA Interface Files
ocrdma1 hca_handle=1 hca_object=23
+GPU
+---
+
+The "gpu" controller regulates the distribution and accounting of
+of GPU-related resources.
+
+GPU Interface Files
+~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+
Misc
----
diff --git a/Documentation/cgroup-v1/drm.rst b/Documentation/cgroup-v1/drm.rst
new file mode 100644
index 000000000000..5f5658e1f5ed
--- /dev/null
+++ b/Documentation/cgroup-v1/drm.rst
@@ -0,0 +1 @@
+Please see ../cgroup-v2.rst for details
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
new file mode 100644
index 000000000000..345af54a5d41
--- /dev/null
+++ b/include/linux/cgroup_drm.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ */
+#ifndef _CGROUP_DRM_H
+#define _CGROUP_DRM_H
+
+#include <linux/cgroup.h>
+
+#ifdef CONFIG_CGROUP_DRM
+
+/**
+ * The DRM cgroup controller data structure.
+ */
+struct drmcg {
+ struct cgroup_subsys_state css;
+};
+
+/**
+ * css_to_drmcg - get the corresponding drmcg ref from a cgroup_subsys_state
+ * @css: the target cgroup_subsys_state
+ *
+ * Return: DRM cgroup that contains the @css
+ */
+static inline struct drmcg *css_to_drmcg(struct cgroup_subsys_state *css)
+{
+ return css ? container_of(css, struct drmcg, css) : NULL;
+}
+
+/**
+ * drmcg_get - get the drmcg reference that a task belongs to
+ * @task: the target task
+ *
+ * This increase the reference count of the css that the @task belongs to
+ *
+ * Return: reference to the DRM cgroup the task belongs to
+ */
+static inline struct drmcg *drmcg_get(struct task_struct *task)
+{
+ return css_to_drmcg(task_get_css(task, gpu_cgrp_id));
+}
+
+/**
+ * drmcg_put - put a drmcg reference
+ * @drmcg: the target drmcg
+ *
+ * Put a reference obtained via drmcg_get
+ */
+static inline void drmcg_put(struct drmcg *drmcg)
+{
+ if (drmcg)
+ css_put(&drmcg->css);
+}
+
+/**
+ * drmcg_parent - find the parent of a drm cgroup
+ * @cg: the target drmcg
+ *
+ * This does not increase the reference count of the parent cgroup
+ *
+ * Return: parent DRM cgroup of @cg
+ */
+static inline struct drmcg *drmcg_parent(struct drmcg *cg)
+{
+ return css_to_drmcg(cg->css.parent);
+}
+
+#else /* CONFIG_CGROUP_DRM */
+
+struct drmcg {
+};
+
+static inline struct drmcg *css_to_drmcg(struct cgroup_subsys_state *css)
+{
+ return NULL;
+}
+
+static inline struct drmcg *drmcg_get(struct task_struct *task)
+{
+ return NULL;
+}
+
+static inline void drmcg_put(struct drmcg *drmcg)
+{
+}
+
+static inline struct drmcg *drmcg_parent(struct drmcg *cg)
+{
+ return NULL;
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* _CGROUP_DRM_H */
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index acb77dcff3b4..f4e627942115 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -61,6 +61,10 @@ SUBSYS(pids)
SUBSYS(rdma)
#endif
+#if IS_ENABLED(CONFIG_CGROUP_DRM)
+SUBSYS(gpu)
+#endif
+
/*
* The following subsystems are not supported on the default hierarchy.
*/
diff --git a/init/Kconfig b/init/Kconfig
index a34064a031a5..bb78dff44d9d 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -965,6 +965,11 @@ config CGROUP_RDMA
Attaching processes with active RDMA resources to the cgroup
hierarchy is allowed even if can cross the hierarchy's limit.
+config CGROUP_DRM
+ bool "DRM controller (EXPERIMENTAL)"
+ help
+ Provides accounting and enforcement of resources in the DRM subsystem.
+
config CGROUP_FREEZER
bool "Freezer controller"
help
diff --git a/kernel/cgroup/Makefile b/kernel/cgroup/Makefile
index 5d7a76bfbbb7..31f186f58121 100644
--- a/kernel/cgroup/Makefile
+++ b/kernel/cgroup/Makefile
@@ -4,5 +4,6 @@ obj-y := cgroup.o rstat.o namespace.o cgroup-v1.o freezer.o
obj-$(CONFIG_CGROUP_FREEZER) += legacy_freezer.o
obj-$(CONFIG_CGROUP_PIDS) += pids.o
obj-$(CONFIG_CGROUP_RDMA) += rdma.o
+obj-$(CONFIG_CGROUP_DRM) += drm.o
obj-$(CONFIG_CPUSETS) += cpuset.o
obj-$(CONFIG_CGROUP_DEBUG) += debug.o
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
new file mode 100644
index 000000000000..5e38a8230922
--- /dev/null
+++ b/kernel/cgroup/drm.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: MIT
+// Copyright 2019 Advanced Micro Devices, Inc.
+#include <linux/slab.h>
+#include <linux/cgroup.h>
+#include <linux/cgroup_drm.h>
+
+static struct drmcg *root_drmcg __read_mostly;
+
+static void drmcg_css_free(struct cgroup_subsys_state *css)
+{
+ struct drmcg *drmcg = css_to_drmcg(css);
+
+ kfree(drmcg);
+}
+
+static struct cgroup_subsys_state *
+drmcg_css_alloc(struct cgroup_subsys_state *parent_css)
+{
+ struct drmcg *parent = css_to_drmcg(parent_css);
+ struct drmcg *drmcg;
+
+ drmcg = kzalloc(sizeof(struct drmcg), GFP_KERNEL);
+ if (!drmcg)
+ return ERR_PTR(-ENOMEM);
+
+ if (!parent)
+ root_drmcg = drmcg;
+
+ return &drmcg->css;
+}
+
+struct cftype files[] = {
+ { } /* terminate */
+};
+
+struct cgroup_subsys gpu_cgrp_subsys = {
+ .css_alloc = drmcg_css_alloc,
+ .css_free = drmcg_css_free,
+ .early_init = false,
+ .legacy_cftypes = files,
+ .dfl_cftypes = files,
+};
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 02/11] drm, cgroup: Bind drm and cgroup subsystem
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
2020-02-26 19:01 ` [PATCH v2 01/11] cgroup: Introduce cgroup for drm subsystem Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 03/11] drm, cgroup: Initialize drmcg properties Kenny Ho
` (9 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
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 subsystem as the drm core initialize/exit.
drmcg_register_dev/drmcg_unregister_dev - used to register/unregister
drm devices to the cgroup subsystem as the devices are presented/removed
from userspace.
Change-Id: I1cb6b2080fc7d27979d886ef23e784341efafb41
---
drivers/gpu/drm/drm_drv.c | 8 +++
include/drm/drm_cgroup.h | 39 +++++++++++
include/linux/cgroup_drm.h | 4 ++
kernel/cgroup/drm.c | 131 +++++++++++++++++++++++++++++++++++++
4 files changed, 182 insertions(+)
create mode 100644 include/drm/drm_cgroup.h
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7c18a980cd4b..e418a61f5c85 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -41,6 +41,7 @@
#include <drm/drm_file.h>
#include <drm/drm_mode_object.h>
#include <drm/drm_print.h>
+#include <drm/drm_cgroup.h>
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -973,6 +974,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
ret = 0;
+ drmcg_register_dev(dev);
+
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor,
driver->patchlevel, driver->date,
@@ -1007,6 +1010,8 @@ EXPORT_SYMBOL(drm_dev_register);
*/
void drm_dev_unregister(struct drm_device *dev)
{
+ drmcg_unregister_dev(dev);
+
if (drm_core_check_feature(dev, DRIVER_LEGACY))
drm_lastclose(dev);
@@ -1113,6 +1118,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drmcg_unbind();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1139,6 +1145,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drmcg_bind(&drm_minor_acquire, &drm_dev_put);
+
drm_core_init_complete = true;
DRM_DEBUG("Initialized\n");
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
new file mode 100644
index 000000000000..530c9a0b3238
--- /dev/null
+++ b/include/drm/drm_cgroup.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ */
+#ifndef __DRM_CGROUP_H__
+#define __DRM_CGROUP_H__
+
+#ifdef CONFIG_CGROUP_DRM
+
+void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
+ void (*put_ddev)(struct drm_device *dev));
+
+void drmcg_unbind(void);
+
+void drmcg_register_dev(struct drm_device *dev);
+
+void drmcg_unregister_dev(struct drm_device *dev);
+
+#else
+
+static inline void drmcg_bind(
+ struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
+ void (*put_ddev)(struct drm_device *dev))
+{
+}
+
+static inline void drmcg_unbind(void)
+{
+}
+
+static inline void drmcg_register_dev(struct drm_device *dev)
+{
+}
+
+static inline void drmcg_unregister_dev(struct drm_device *dev)
+{
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* __DRM_CGROUP_H__ */
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 345af54a5d41..307bb75db248 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -5,6 +5,10 @@
#define _CGROUP_DRM_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)
#ifdef CONFIG_CGROUP_DRM
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 5e38a8230922..061bb9c458e4 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -1,11 +1,142 @@
// SPDX-License-Identifier: MIT
// Copyright 2019 Advanced Micro Devices, Inc.
+#include <linux/bitmap.h>
+#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/cgroup.h>
#include <linux/cgroup_drm.h>
+#include <drm/drm_file.h>
+#include <drm/drm_device.h>
+#include <drm/drm_cgroup.h>
static struct drmcg *root_drmcg __read_mostly;
+/* global mutex for drmcg across all devices */
+static DEFINE_MUTEX(drmcg_mutex);
+
+static DECLARE_BITMAP(known_devs, MAX_DRM_DEV);
+
+static struct drm_minor (*(*acquire_drm_minor)(unsigned int minor_id));
+
+static void (*put_drm_dev)(struct drm_device *dev);
+
+/**
+ * drmcg_bind - Bind DRM subsystem to cgroup subsystem
+ * @acq_dm: function pointer to the drm_minor_acquire function
+ * @put_ddev: function pointer to the drm_dev_put function
+ *
+ * This function binds some functions from the DRM subsystem and make
+ * them available to the drmcg subsystem.
+ *
+ * drmcg_unbind does the opposite of this function
+ */
+void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
+ void (*put_ddev)(struct drm_device *dev))
+{
+ mutex_lock(&drmcg_mutex);
+ acquire_drm_minor = acq_dm;
+ put_drm_dev = put_ddev;
+ mutex_unlock(&drmcg_mutex);
+}
+EXPORT_SYMBOL(drmcg_bind);
+
+/**
+ * drmcg_unbind - Unbind DRM subsystem from cgroup subsystem
+ *
+ * drmcg_bind does the opposite of this function
+ */
+void drmcg_unbind(void)
+{
+ mutex_lock(&drmcg_mutex);
+ acquire_drm_minor = NULL;
+ put_drm_dev = NULL;
+ mutex_unlock(&drmcg_mutex);
+}
+EXPORT_SYMBOL(drmcg_unbind);
+
+/**
+ * drmcg_register_dev - register a DRM device for usage in drm cgroup
+ * @dev: DRM device
+ *
+ * This function make a DRM device visible to the cgroup subsystem.
+ * Once the drmcg is aware of the device, drmcg can start tracking and
+ * control resource usage for said device.
+ *
+ * drmcg_unregister_dev reverse the operation of this function
+ */
+void drmcg_register_dev(struct drm_device *dev)
+{
+ if (WARN_ON(dev->primary->index >= MAX_DRM_DEV))
+ return;
+
+ mutex_lock(&drmcg_mutex);
+ set_bit(dev->primary->index, known_devs);
+ mutex_unlock(&drmcg_mutex);
+}
+EXPORT_SYMBOL(drmcg_register_dev);
+
+/**
+ * drmcg_unregister_dev - Iterate through all stored DRM minors
+ * @dev: DRM device
+ *
+ * Unregister @dev so that drmcg no longer control resource usage
+ * of @dev. The @dev was registered to drmcg using
+ * drmcg_register_dev function
+ */
+void drmcg_unregister_dev(struct drm_device *dev)
+{
+ if (WARN_ON(dev->primary->index >= MAX_DRM_DEV))
+ return;
+
+ mutex_lock(&drmcg_mutex);
+ clear_bit(dev->primary->index, known_devs);
+ mutex_unlock(&drmcg_mutex);
+}
+EXPORT_SYMBOL(drmcg_unregister_dev);
+
+/**
+ * drm_minor_for_each - Iterate through all stored DRM minors
+ * @fn: Function to be called for each pointer.
+ * @data: Data passed to callback function.
+ *
+ * The callback function will be called for each registered device, passing
+ * the minor, the @drm_minor entry and @data.
+ *
+ * If @fn returns anything other than %0, the iteration stops and that
+ * value is returned from this function.
+ */
+static int drm_minor_for_each(int (*fn)(int id, void *p, void *data),
+ void *data)
+{
+ int rc = 0;
+
+ mutex_lock(&drmcg_mutex);
+ if (acquire_drm_minor) {
+ unsigned int minor;
+ struct drm_minor *dm;
+
+ minor = find_next_bit(known_devs, MAX_DRM_DEV, 0);
+ while (minor < MAX_DRM_DEV) {
+ dm = acquire_drm_minor(minor);
+
+ if (IS_ERR(dm))
+ continue;
+
+ rc = fn(minor, (void *)dm, data);
+
+ put_drm_dev(dm->dev); /* release from acquire_drm_minor */
+
+ if (rc)
+ break;
+
+ minor = find_next_bit(known_devs, MAX_DRM_DEV, minor+1);
+ }
+ }
+ mutex_unlock(&drmcg_mutex);
+
+ return rc;
+}
+
static void drmcg_css_free(struct cgroup_subsys_state *css)
{
struct drmcg *drmcg = css_to_drmcg(css);
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 03/11] drm, cgroup: Initialize drmcg properties
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
2020-02-26 19:01 ` [PATCH v2 01/11] cgroup: Introduce cgroup for drm subsystem Kenny Ho
2020-02-26 19:01 ` [PATCH v2 02/11] drm, cgroup: Bind drm and cgroup subsystem Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 04/11] drm, cgroup: Add total GEM buffer allocation stats Kenny Ho
` (8 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
drmcg initialization involves allocating a per cgroup, per device data
structure and setting the defaults. There are two entry points for
drmcg init:
1) When struct drmcg is created via css_alloc, initialization is done
for each device
2) When DRM devices are created after drmcgs are created
a) Per device drmcg data structure is allocated at the beginning of
DRM device creation such that drmcg can begin tracking usage
statistics
b) At the end of DRM device creation, drmcg_register_dev will update in
case device specific defaults need to be applied.
Entry point #2 usually 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 <Kenny.Ho@amd.com>
---
drivers/gpu/drm/drm_drv.c | 4 ++
include/drm/drm_cgroup.h | 18 +++++++
include/drm/drm_device.h | 7 +++
include/drm/drm_drv.h | 9 ++++
include/linux/cgroup_drm.h | 12 +++++
kernel/cgroup/drm.c | 105 +++++++++++++++++++++++++++++++++++++
6 files changed, 155 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e418a61f5c85..e10bd42ebdba 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -644,6 +644,7 @@ int drm_dev_init(struct drm_device *dev,
mutex_init(&dev->filelist_mutex);
mutex_init(&dev->clientlist_mutex);
mutex_init(&dev->master_mutex);
+ mutex_init(&dev->drmcg_mutex);
dev->anon_inode = drm_fs_inode_new();
if (IS_ERR(dev->anon_inode)) {
@@ -680,6 +681,7 @@ int drm_dev_init(struct drm_device *dev,
if (ret)
goto err_setunique;
+ drmcg_device_early_init(dev);
return 0;
err_setunique:
@@ -694,6 +696,7 @@ int drm_dev_init(struct drm_device *dev,
drm_fs_inode_free(dev->anon_inode);
err_free:
put_device(dev->dev);
+ mutex_destroy(&dev->drmcg_mutex);
mutex_destroy(&dev->master_mutex);
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
@@ -770,6 +773,7 @@ void drm_dev_fini(struct drm_device *dev)
put_device(dev->dev);
+ mutex_destroy(&dev->drmcg_mutex);
mutex_destroy(&dev->master_mutex);
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 530c9a0b3238..fda426fba035 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -4,8 +4,17 @@
#ifndef __DRM_CGROUP_H__
#define __DRM_CGROUP_H__
+#include <linux/cgroup_drm.h>
+
#ifdef CONFIG_CGROUP_DRM
+/**
+ * Per DRM device properties for DRM cgroup controller for the purpose
+ * of storing per device defaults
+ */
+struct drmcg_props {
+};
+
void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
void (*put_ddev)(struct drm_device *dev));
@@ -15,8 +24,13 @@ void drmcg_register_dev(struct drm_device *dev);
void drmcg_unregister_dev(struct drm_device *dev);
+void drmcg_device_early_init(struct drm_device *device);
+
#else
+struct drmcg_props {
+};
+
static inline void drmcg_bind(
struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
void (*put_ddev)(struct drm_device *dev))
@@ -35,5 +49,9 @@ static inline void drmcg_unregister_dev(struct drm_device *dev)
{
}
+static inline void drmcg_device_early_init(struct drm_device *device)
+{
+}
+
#endif /* CONFIG_CGROUP_DRM */
#endif /* __DRM_CGROUP_H__ */
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 1acfc3bbd3fb..a94598b8f670 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -8,6 +8,7 @@
#include <drm/drm_hashtab.h>
#include <drm/drm_mode_config.h>
+#include <drm/drm_cgroup.h>
struct drm_driver;
struct drm_minor;
@@ -308,6 +309,12 @@ struct drm_device {
*/
struct drm_fb_helper *fb_helper;
+ /** \name DRM Cgroup */
+ /*@{ */
+ struct mutex drmcg_mutex;
+ struct drmcg_props drmcg_props;
+ /*@} */
+
/* Everything below here is for legacy driver, never use! */
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index cf13470810a5..1f65ac4d9bbf 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -715,6 +715,15 @@ struct drm_driver {
struct drm_device *dev,
uint32_t handle);
+ /**
+ * @drmcg_custom_init
+ *
+ * Optional callback used to initialize drm cgroup per device properties
+ * such as resource limit defaults.
+ */
+ void (*drmcg_custom_init)(struct drm_device *dev,
+ struct drmcg_props *props);
+
/**
* @gem_vm_ops: Driver private ops for this object
*
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 307bb75db248..ff94b48aa2dc 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -4,6 +4,7 @@
#ifndef _CGROUP_DRM_H
#define _CGROUP_DRM_H
+#include <linux/mutex.h>
#include <linux/cgroup.h>
#include <drm/drm_file.h>
@@ -12,11 +13,19 @@
#ifdef CONFIG_CGROUP_DRM
+/**
+ * Per DRM cgroup, per device resources (such as statistics and limits)
+ */
+struct drmcg_device_resource {
+ /* for per device stats */
+};
+
/**
* The DRM cgroup controller data structure.
*/
struct drmcg {
struct cgroup_subsys_state css;
+ struct drmcg_device_resource *dev_resources[MAX_DRM_DEV];
};
/**
@@ -70,6 +79,9 @@ static inline struct drmcg *drmcg_parent(struct drmcg *cg)
#else /* CONFIG_CGROUP_DRM */
+struct drmcg_device_resource {
+};
+
struct drmcg {
};
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 061bb9c458e4..351df517d5a6 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -1,11 +1,17 @@
// SPDX-License-Identifier: MIT
// Copyright 2019 Advanced Micro Devices, Inc.
#include <linux/bitmap.h>
+#include <linux/export.h>
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/cgroup.h>
+#include <linux/fs.h>
+#include <linux/seq_file.h>
+#include <linux/mutex.h>
+#include <linux/kernel.h>
#include <linux/cgroup_drm.h>
#include <drm/drm_file.h>
+#include <drm/drm_drv.h>
#include <drm/drm_device.h>
#include <drm/drm_cgroup.h>
@@ -54,6 +60,47 @@ void drmcg_unbind(void)
}
EXPORT_SYMBOL(drmcg_unbind);
+/* caller must hold dev->drmcg_mutex */
+static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
+{
+ int minor = dev->primary->index;
+ struct drmcg_device_resource *ddr = drmcg->dev_resources[minor];
+
+ if (ddr == NULL) {
+ ddr = kzalloc(sizeof(struct drmcg_device_resource),
+ GFP_KERNEL);
+
+ if (!ddr)
+ return -ENOMEM;
+ }
+
+ drmcg->dev_resources[minor] = ddr;
+
+ /* set defaults here */
+
+ return 0;
+}
+
+static inline void drmcg_update_cg_tree(struct drm_device *dev)
+{
+ struct cgroup_subsys_state *pos;
+ struct drmcg *child;
+
+ if (root_drmcg == NULL)
+ return;
+
+ /* init cgroups created before registration (i.e. root cgroup) */
+
+ /* use cgroup_mutex instead of rcu_read_lock because
+ * init_drmcg_single has alloc which may sleep */
+ mutex_lock(&cgroup_mutex);
+ css_for_each_descendant_pre(pos, &root_drmcg->css) {
+ child = css_to_drmcg(pos);
+ init_drmcg_single(child, dev);
+ }
+ mutex_unlock(&cgroup_mutex);
+}
+
/**
* drmcg_register_dev - register a DRM device for usage in drm cgroup
* @dev: DRM device
@@ -71,6 +118,13 @@ void drmcg_register_dev(struct drm_device *dev)
mutex_lock(&drmcg_mutex);
set_bit(dev->primary->index, known_devs);
+
+ if (dev->driver->drmcg_custom_init)
+ {
+ dev->driver->drmcg_custom_init(dev, &dev->drmcg_props);
+
+ drmcg_update_cg_tree(dev);
+ }
mutex_unlock(&drmcg_mutex);
}
EXPORT_SYMBOL(drmcg_register_dev);
@@ -137,23 +191,61 @@ static int drm_minor_for_each(int (*fn)(int id, void *p, void *data),
return rc;
}
+static int drmcg_css_free_fn(int id, void *ptr, void *data)
+{
+ struct drm_minor *minor = ptr;
+ struct drmcg *drmcg = data;
+
+ if (minor->type != DRM_MINOR_PRIMARY)
+ return 0;
+
+ kfree(drmcg->dev_resources[minor->index]);
+
+ return 0;
+}
+
static void drmcg_css_free(struct cgroup_subsys_state *css)
{
struct drmcg *drmcg = css_to_drmcg(css);
+ drm_minor_for_each(&drmcg_css_free_fn, drmcg);
+
kfree(drmcg);
}
+static int init_drmcg_fn(int id, void *ptr, void *data)
+{
+ struct drm_minor *minor = ptr;
+ struct drmcg *drmcg = data;
+ int rc;
+
+ if (minor->type != DRM_MINOR_PRIMARY)
+ return 0;
+
+ mutex_lock(&minor->dev->drmcg_mutex);
+ rc = init_drmcg_single(drmcg, minor->dev);
+ mutex_unlock(&minor->dev->drmcg_mutex);
+
+ return rc;
+}
+
static struct cgroup_subsys_state *
drmcg_css_alloc(struct cgroup_subsys_state *parent_css)
{
struct drmcg *parent = css_to_drmcg(parent_css);
struct drmcg *drmcg;
+ int rc;
drmcg = kzalloc(sizeof(struct drmcg), GFP_KERNEL);
if (!drmcg)
return ERR_PTR(-ENOMEM);
+ rc = drm_minor_for_each(&init_drmcg_fn, drmcg);
+ if (rc) {
+ drmcg_css_free(&drmcg->css);
+ return ERR_PTR(rc);
+ }
+
if (!parent)
root_drmcg = drmcg;
@@ -171,3 +263,16 @@ struct cgroup_subsys gpu_cgrp_subsys = {
.legacy_cftypes = files,
.dfl_cftypes = files,
};
+
+/**
+ * drmcg_device_early_init - initialize device specific resources for DRM cgroups
+ * @dev: the target DRM device
+ *
+ * Allocate and initialize device specific resources for existing DRM cgroups.
+ * Typically only the root cgroup exists before the initialization of @dev.
+ */
+void drmcg_device_early_init(struct drm_device *dev)
+{
+ drmcg_update_cg_tree(dev);
+}
+EXPORT_SYMBOL(drmcg_device_early_init);
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 04/11] drm, cgroup: Add total GEM buffer allocation stats
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (2 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 03/11] drm, cgroup: Initialize drmcg properties Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 05/11] drm, cgroup: Add peak " Kenny Ho
` (7 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
The drm resource being measured here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of cgroup accounting and limiting, ownership of the
buffer is deemed to be the cgroup for which the allocating process
belongs to. There is one cgroup stats per drm device. Each allocation
is charged to the owning cgroup as well as all its ancestors.
Similar to the memory cgroup, migrating a process to a different cgroup
does not move the GEM buffer usages that the process started while in
previous cgroup, to the new cgroup.
The following is an example to illustrate some of the operations. Given
the following cgroup hierarchy (The letters are cgroup names with R
being the root cgroup. The numbers in brackets are processes. The
processes are placed with cgroup's 'No Internal Process Constraint' in
mind, so no process is placed in cgroup B.)
R (4, 5) ------ A (6)
\
B ---- C (7,8)
\
D (9)
Here is a list of operation and the associated effect on the size
track by the cgroups (for simplicity, each buffer is 1 unit in size.)
== == == == == ===================================================
R A B C D Ops
== == == == == ===================================================
1 0 0 0 0 4 allocated a buffer
1 0 0 0 0 4 shared a buffer with 5
1 0 0 0 0 4 shared a buffer with 9
2 0 1 0 1 9 allocated a buffer
3 0 2 1 1 7 allocated a buffer
3 0 2 1 1 7 shared a buffer with 8
3 0 2 1 1 7 sharing with 9
3 0 2 1 1 7 release a buffer
3 0 2 1 1 7 migrate to cgroup D
3 0 2 1 1 9 release a buffer from 7
2 0 1 0 1 8 release a buffer from 7 (last ref to shared buf)
== == == == == ===================================================
gpu.buffer.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total GEM buffer allocation in bytes.
Change-Id: Ibc1f646ca7dbc588e2d11802b156b524696a23e7
Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 50 +++++++++-
drivers/gpu/drm/drm_gem.c | 9 ++
include/drm/drm_cgroup.h | 16 +++
include/drm/drm_gem.h | 10 ++
include/linux/cgroup_drm.h | 6 ++
kernel/cgroup/drm.c | 126 ++++++++++++++++++++++++
6 files changed, 216 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 7deff912185e..c041e672cc10 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -63,6 +63,7 @@ v1 is available under Documentation/admin-guide/cgroup-v1/.
5-7-1. RDMA Interface Files
5-8. GPU
5-8-1. GPU Interface Files
+ 5-8-2. GEM Buffer Ownership
5-9. Misc
5-9-1. perf_event
5-N. Non-normative information
@@ -2068,7 +2069,54 @@ of GPU-related resources.
GPU Interface Files
~~~~~~~~~~~~~~~~~~~~
-TODO
+ gpu.buffer.stats
+ A read-only flat-keyed file which exists on all cgroups. Each
+ entry is keyed by the drm device's major:minor.
+
+ Total GEM buffer allocation in bytes.
+
+GEM Buffer Ownership
+~~~~~~~~~~~~~~~~~~~~
+
+For the purpose of cgroup accounting and limiting, ownership of the
+buffer is deemed to be the cgroup for which the allocating process
+belongs to. There is one cgroup stats per drm device. Each allocation
+is charged to the owning cgroup as well as all its ancestors.
+
+Similar to the memory cgroup, migrating a process to a different cgroup
+does not move the GEM buffer usages that the process started while in
+previous cgroup, to the new cgroup.
+
+The following is an example to illustrate some of the operations. Given
+the following cgroup hierarchy (The letters are cgroup names with R
+being the root cgroup. The numbers in brackets are processes. The
+processes are placed with cgroup's 'No Internal Process Constraint' in
+mind, so no process is placed in cgroup B.)
+
+R (4, 5) ------ A (6)
+ \
+ B ---- C (7,8)
+ \
+ D (9)
+
+Here is a list of operation and the associated effect on the size
+track by the cgroups (for simplicity, each buffer is 1 unit in size.)
+
+== == == == == ===================================================
+R A B C D Ops
+== == == == == ===================================================
+1 0 0 0 0 4 allocated a buffer
+1 0 0 0 0 4 shared a buffer with 5
+1 0 0 0 0 4 shared a buffer with 9
+2 0 1 0 1 9 allocated a buffer
+3 0 2 1 1 7 allocated a buffer
+3 0 2 1 1 7 shared a buffer with 8
+3 0 2 1 1 7 sharing with 9
+3 0 2 1 1 7 release a buffer
+3 0 2 1 1 7 migrate to cgroup D
+3 0 2 1 1 9 release a buffer from 7
+2 0 1 0 1 8 release a buffer from 7 (last ref to shared buf)
+== == == == == ===================================================
Misc
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a9e4a610445a..589f8f6bde2c 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -38,6 +38,7 @@
#include <linux/dma-buf.h>
#include <linux/mem_encrypt.h>
#include <linux/pagevec.h>
+#include <linux/cgroup_drm.h>
#include <drm/drm.h>
#include <drm/drm_device.h>
@@ -46,6 +47,7 @@
#include <drm/drm_gem.h>
#include <drm/drm_print.h>
#include <drm/drm_vma_manager.h>
+#include <drm/drm_cgroup.h>
#include "drm_internal.h"
@@ -164,6 +166,9 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->resv = &obj->_resv;
drm_vma_node_reset(&obj->vma_node);
+
+ obj->drmcg = drmcg_get(current);
+ drmcg_chg_bo_alloc(obj->drmcg, dev, size);
}
EXPORT_SYMBOL(drm_gem_private_object_init);
@@ -957,6 +962,10 @@ drm_gem_object_release(struct drm_gem_object *obj)
fput(obj->filp);
dma_resv_fini(&obj->_resv);
+
+ drmcg_unchg_bo_alloc(obj->drmcg, obj->dev, obj->size);
+ drmcg_put(obj->drmcg);
+
drm_gem_free_mmap_offset(obj);
}
EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index fda426fba035..1eb3012e16a1 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -26,6 +26,12 @@ void drmcg_unregister_dev(struct drm_device *dev);
void drmcg_device_early_init(struct drm_device *device);
+void drmcg_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
+ size_t size);
+
+void drmcg_unchg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
+ size_t size);
+
#else
struct drmcg_props {
@@ -53,5 +59,15 @@ static inline void drmcg_device_early_init(struct drm_device *device)
{
}
+static inline void drmcg_chg_bo_alloc(struct drmcg *drmcg,
+ struct drm_device *dev, size_t size)
+{
+}
+
+static inline void drmcg_unchg_bo_alloc(struct drmcg *drmcg,
+ struct drm_device *dev, size_t size)
+{
+}
+
#endif /* CONFIG_CGROUP_DRM */
#endif /* __DRM_CGROUP_H__ */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b375069cd48..9c588c329da0 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -310,6 +310,16 @@ struct drm_gem_object {
*
*/
const struct drm_gem_object_funcs *funcs;
+
+ /**
+ * @drmcg:
+ *
+ * DRM cgroup this GEM object belongs to.
+ *
+ * This is used to track and limit the amount of GEM objects a user
+ * can allocate.
+ */
+ struct drmcg *drmcg;
};
/**
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index ff94b48aa2dc..34b0aec7c964 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -11,6 +11,11 @@
/* limit defined per the way drm_minor_alloc operates */
#define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
+enum drmcg_res_type {
+ DRMCG_TYPE_BO_TOTAL,
+ __DRMCG_TYPE_LAST,
+};
+
#ifdef CONFIG_CGROUP_DRM
/**
@@ -18,6 +23,7 @@
*/
struct drmcg_device_resource {
/* for per device stats */
+ s64 bo_stats_total_allocated;
};
/**
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 351df517d5a6..addb096edac5 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -13,6 +13,7 @@
#include <drm/drm_file.h>
#include <drm/drm_drv.h>
#include <drm/drm_device.h>
+#include <drm/drm_ioctl.h>
#include <drm/drm_cgroup.h>
static struct drmcg *root_drmcg __read_mostly;
@@ -26,6 +27,18 @@ static struct drm_minor (*(*acquire_drm_minor)(unsigned int minor_id));
static void (*put_drm_dev)(struct drm_device *dev);
+#define DRMCG_CTF_PRIV_SIZE 3
+#define DRMCG_CTF_PRIV_MASK GENMASK((DRMCG_CTF_PRIV_SIZE - 1), 0)
+#define DRMCG_CTF_PRIV(res_type, f_type) ((res_type) <<\
+ DRMCG_CTF_PRIV_SIZE | (f_type))
+#define DRMCG_CTF_PRIV2RESTYPE(priv) ((priv) >> DRMCG_CTF_PRIV_SIZE)
+#define DRMCG_CTF_PRIV2FTYPE(priv) ((priv) & DRMCG_CTF_PRIV_MASK)
+
+
+enum drmcg_file_type {
+ DRMCG_FTYPE_STATS,
+};
+
/**
* drmcg_bind - Bind DRM subsystem to cgroup subsystem
* @acq_dm: function pointer to the drm_minor_acquire function
@@ -252,7 +265,66 @@ drmcg_css_alloc(struct cgroup_subsys_state *parent_css)
return &drmcg->css;
}
+static void drmcg_print_stats(struct drmcg_device_resource *ddr,
+ struct seq_file *sf, enum drmcg_res_type type)
+{
+ if (ddr == NULL) {
+ seq_puts(sf, "\n");
+ return;
+ }
+
+ switch (type) {
+ case DRMCG_TYPE_BO_TOTAL:
+ seq_printf(sf, "%lld\n", ddr->bo_stats_total_allocated);
+ break;
+ default:
+ seq_puts(sf, "\n");
+ break;
+ }
+}
+
+static int drmcg_seq_show_fn(int id, void *ptr, void *data)
+{
+ struct drm_minor *minor = ptr;
+ struct seq_file *sf = data;
+ struct drmcg *drmcg = css_to_drmcg(seq_css(sf));
+ enum drmcg_file_type f_type =
+ DRMCG_CTF_PRIV2FTYPE(seq_cft(sf)->private);
+ enum drmcg_res_type type =
+ DRMCG_CTF_PRIV2RESTYPE(seq_cft(sf)->private);
+ struct drmcg_device_resource *ddr;
+
+ if (minor->type != DRM_MINOR_PRIMARY)
+ return 0;
+
+ ddr = drmcg->dev_resources[minor->index];
+
+ seq_printf(sf, "%d:%d ", DRM_MAJOR, minor->index);
+
+ switch (f_type) {
+ case DRMCG_FTYPE_STATS:
+ drmcg_print_stats(ddr, sf, type);
+ break;
+ default:
+ seq_puts(sf, "\n");
+ break;
+ }
+
+ return 0;
+}
+
+int drmcg_seq_show(struct seq_file *sf, void *v)
+{
+ return drm_minor_for_each(&drmcg_seq_show_fn, sf);
+}
+
struct cftype files[] = {
+ {
+ .name = "buffer.total.stats",
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_TOTAL,
+ DRMCG_FTYPE_STATS),
+ },
{ } /* terminate */
};
@@ -276,3 +348,57 @@ void drmcg_device_early_init(struct drm_device *dev)
drmcg_update_cg_tree(dev);
}
EXPORT_SYMBOL(drmcg_device_early_init);
+
+/**
+ * drmcg_chg_bo_alloc - charge GEM buffer usage for a device and cgroup
+ * @drmcg: the DRM cgroup to be charged to
+ * @dev: the device the usage should be charged to
+ * @size: size of the GEM buffer to be accounted for
+ *
+ * This function should be called when a new GEM buffer is allocated to account
+ * for the utilization. This should not be called when the buffer is shared (
+ * the GEM buffer's reference count being incremented.)
+ */
+void drmcg_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
+ size_t size)
+{
+ struct drmcg_device_resource *ddr;
+ int devIdx = dev->primary->index;
+
+ if (drmcg == NULL)
+ return;
+
+ mutex_lock(&dev->drmcg_mutex);
+ for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg)) {
+ ddr = drmcg->dev_resources[devIdx];
+
+ ddr->bo_stats_total_allocated += (s64)size;
+ }
+ mutex_unlock(&dev->drmcg_mutex);
+}
+EXPORT_SYMBOL(drmcg_chg_bo_alloc);
+
+/**
+ * drmcg_unchg_bo_alloc -
+ * @drmcg: the DRM cgroup to uncharge from
+ * @dev: the device the usage should be removed from
+ * @size: size of the GEM buffer to be accounted for
+ *
+ * This function should be called when the GEM buffer is about to be freed (
+ * not simply when the GEM buffer's reference count is being decremented.)
+ */
+void drmcg_unchg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
+ size_t size)
+{
+ int devIdx = dev->primary->index;
+
+ if (drmcg == NULL)
+ return;
+
+ mutex_lock(&dev->drmcg_mutex);
+ for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg))
+ drmcg->dev_resources[devIdx]->bo_stats_total_allocated
+ -= (s64)size;
+ mutex_unlock(&dev->drmcg_mutex);
+}
+EXPORT_SYMBOL(drmcg_unchg_bo_alloc);
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 05/11] drm, cgroup: Add peak GEM buffer allocation stats
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (3 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 04/11] drm, cgroup: Add total GEM buffer allocation stats Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 06/11] drm, cgroup: Add GEM buffer allocation count stats Kenny Ho
` (6 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
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 <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 6 ++++++
include/linux/cgroup_drm.h | 3 +++
kernel/cgroup/drm.c | 12 ++++++++++++
3 files changed, 21 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index c041e672cc10..6199cc9a978f 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2075,6 +2075,12 @@ GPU Interface Files
Total GEM buffer allocation in bytes.
+ 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.
+
GEM Buffer Ownership
~~~~~~~~~~~~~~~~~~~~
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 34b0aec7c964..d90807627213 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -13,6 +13,7 @@
enum drmcg_res_type {
DRMCG_TYPE_BO_TOTAL,
+ DRMCG_TYPE_BO_PEAK,
__DRMCG_TYPE_LAST,
};
@@ -24,6 +25,8 @@ enum drmcg_res_type {
struct drmcg_device_resource {
/* for per device stats */
s64 bo_stats_total_allocated;
+
+ s64 bo_stats_peak_allocated;
};
/**
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index addb096edac5..68b23693418b 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -277,6 +277,9 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
case DRMCG_TYPE_BO_TOTAL:
seq_printf(sf, "%lld\n", ddr->bo_stats_total_allocated);
break;
+ case DRMCG_TYPE_BO_PEAK:
+ seq_printf(sf, "%lld\n", ddr->bo_stats_peak_allocated);
+ break;
default:
seq_puts(sf, "\n");
break;
@@ -325,6 +328,12 @@ struct cftype files[] = {
.private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_TOTAL,
DRMCG_FTYPE_STATS),
},
+ {
+ .name = "buffer.peak.stats",
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_PEAK,
+ DRMCG_FTYPE_STATS),
+ },
{ } /* terminate */
};
@@ -373,6 +382,9 @@ void drmcg_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
ddr = drmcg->dev_resources[devIdx];
ddr->bo_stats_total_allocated += (s64)size;
+
+ if (ddr->bo_stats_peak_allocated < (s64)size)
+ ddr->bo_stats_peak_allocated = (s64)size;
}
mutex_unlock(&dev->drmcg_mutex);
}
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 06/11] drm, cgroup: Add GEM buffer allocation count stats
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (4 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 05/11] drm, cgroup: Add peak " Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 07/11] drm, cgroup: Add total GEM buffer allocation limit Kenny Ho
` (5 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
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 <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 6 ++++++
include/linux/cgroup_drm.h | 3 +++
kernel/cgroup/drm.c | 22 +++++++++++++++++++---
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 6199cc9a978f..065f2b52da57 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2081,6 +2081,12 @@ GPU Interface Files
Largest (high water mark) GEM buffer allocated in bytes.
+ 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.
+
GEM Buffer Ownership
~~~~~~~~~~~~~~~~~~~~
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index d90807627213..103868d972d0 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -14,6 +14,7 @@
enum drmcg_res_type {
DRMCG_TYPE_BO_TOTAL,
DRMCG_TYPE_BO_PEAK,
+ DRMCG_TYPE_BO_COUNT,
__DRMCG_TYPE_LAST,
};
@@ -27,6 +28,8 @@ struct drmcg_device_resource {
s64 bo_stats_total_allocated;
s64 bo_stats_peak_allocated;
+
+ s64 bo_stats_count_allocated;
};
/**
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 68b23693418b..5a700833a304 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -280,6 +280,9 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
case DRMCG_TYPE_BO_PEAK:
seq_printf(sf, "%lld\n", ddr->bo_stats_peak_allocated);
break;
+ case DRMCG_TYPE_BO_COUNT:
+ seq_printf(sf, "%lld\n", ddr->bo_stats_count_allocated);
+ break;
default:
seq_puts(sf, "\n");
break;
@@ -334,6 +337,12 @@ struct cftype files[] = {
.private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_PEAK,
DRMCG_FTYPE_STATS),
},
+ {
+ .name = "buffer.count.stats",
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_COUNT,
+ DRMCG_FTYPE_STATS),
+ },
{ } /* terminate */
};
@@ -385,6 +394,8 @@ void drmcg_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
if (ddr->bo_stats_peak_allocated < (s64)size)
ddr->bo_stats_peak_allocated = (s64)size;
+
+ ddr->bo_stats_count_allocated++;
}
mutex_unlock(&dev->drmcg_mutex);
}
@@ -402,15 +413,20 @@ EXPORT_SYMBOL(drmcg_chg_bo_alloc);
void drmcg_unchg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
size_t size)
{
+ struct drmcg_device_resource *ddr;
int devIdx = dev->primary->index;
if (drmcg == NULL)
return;
mutex_lock(&dev->drmcg_mutex);
- for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg))
- drmcg->dev_resources[devIdx]->bo_stats_total_allocated
- -= (s64)size;
+ for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg)) {
+ ddr = drmcg->dev_resources[devIdx];
+
+ ddr->bo_stats_total_allocated -= (s64)size;
+
+ ddr->bo_stats_count_allocated--;
+ }
mutex_unlock(&dev->drmcg_mutex);
}
EXPORT_SYMBOL(drmcg_unchg_bo_alloc);
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 07/11] drm, cgroup: Add total GEM buffer allocation limit
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (5 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 06/11] drm, cgroup: Add GEM buffer allocation count stats Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 08/11] drm, cgroup: Add peak " Kenny Ho
` (4 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
The drm resource being limited here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of cgroup accounting and limiting, ownership of the
buffer is deemed to be the cgroup for which the allocating process
belongs to. There is one cgroup limit per drm device.
The limiting functionality is added to the previous stats collection
function. The drm_gem_private_object_init is modified to have a return
value to allow failure due to cgroup limit.
The try_chg function only fails if the DRM cgroup properties has
limit_enforced set to true for the DRM device. This is to allow the DRM
cgroup controller to collect usage stats without enforcing the limits.
gpu.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.
gpu.buffer.max
A read-write flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Per device limits on the total GEM buffer allocation in byte.
This is a hard limit. Attempts in allocating beyond the cgroup
limit will result in ENOMEM. Shorthand understood by memparse
(such as k, m, g) can be used.
Set 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 <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 21 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 19 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
drivers/gpu/drm/drm_gem.c | 11 +-
include/drm/drm_cgroup.h | 8 +-
include/drm/drm_gem.h | 2 +-
include/linux/cgroup_drm.h | 1 +
kernel/cgroup/drm.c | 227 ++++++++++++++++++++-
8 files changed, 278 insertions(+), 17 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 065f2b52da57..f2d7abf5c783 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2087,6 +2087,27 @@ GPU Interface Files
Total number of GEM buffer allocated.
+ gpu.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.
+
+ gpu.buffer.max
+ A read-write flat-keyed file which exists on all cgroups. Each
+ entry is keyed by the drm device's major:minor.
+
+ Per device limits on the total GEM buffer allocation in byte.
+ This is a hard limit. Attempts in allocating beyond the cgroup
+ limit will result in ENOMEM. Shorthand understood by memparse
+ (such as k, m, g) can be used.
+
+ Set 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
+
GEM Buffer Ownership
~~~~~~~~~~~~~~~~~~~~
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6e1faf8a2bca..171397708855 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1413,6 +1413,23 @@ amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
stime, etime, mode);
}
+#ifdef CONFIG_CGROUP_DRM
+
+static void amdgpu_drmcg_custom_init(struct drm_device *dev,
+ struct drmcg_props *props)
+{
+ props->limit_enforced = true;
+}
+
+#else
+
+static void amdgpu_drmcg_custom_init(struct drm_device *dev,
+ struct drmcg_props *props)
+{
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+
static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_ATOMIC |
@@ -1444,6 +1461,8 @@ static struct drm_driver kms_driver = {
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
+ .drmcg_custom_init = amdgpu_drmcg_custom_init,
+
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 5766d20f29d8..4d08ccbc541a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -34,6 +34,7 @@
#include <drm/amdgpu_drm.h>
#include <drm/drm_cache.h>
+#include <drm/drm_cgroup.h>
#include "amdgpu.h"
#include "amdgpu_trace.h"
#include "amdgpu_amdkfd.h"
@@ -551,7 +552,10 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
- drm_gem_private_object_init(adev->ddev, &bo->tbo.base, size);
+ if (!drm_gem_private_object_init(adev->ddev, &bo->tbo.base, size)) {
+ kfree(bo);
+ return -ENOMEM;
+ }
INIT_LIST_HEAD(&bo->shadow_list);
bo->vm_bo = NULL;
bo->preferred_domains = bp->preferred_domain ? bp->preferred_domain :
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 589f8f6bde2c..30adf730da0f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -150,11 +150,17 @@ EXPORT_SYMBOL(drm_gem_object_init);
* no GEM provided backing store. Instead the caller is responsible for
* backing the object and handling it.
*/
-void drm_gem_private_object_init(struct drm_device *dev,
+bool drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+ obj->drmcg = drmcg_get(current);
+ if (!drmcg_try_chg_bo_alloc(obj->drmcg, dev, size)) {
+ drmcg_put(obj->drmcg);
+ obj->drmcg = NULL;
+ return false;
+ }
obj->dev = dev;
obj->filp = NULL;
@@ -167,8 +173,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
drm_vma_node_reset(&obj->vma_node);
- obj->drmcg = drmcg_get(current);
- drmcg_chg_bo_alloc(obj->drmcg, dev, size);
+ return true;
}
EXPORT_SYMBOL(drm_gem_private_object_init);
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 1eb3012e16a1..2783e56690db 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -13,6 +13,9 @@
* of storing per device defaults
*/
struct drmcg_props {
+ bool limit_enforced;
+
+ s64 bo_limits_total_allocated_default;
};
void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
@@ -26,7 +29,7 @@ void drmcg_unregister_dev(struct drm_device *dev);
void drmcg_device_early_init(struct drm_device *device);
-void drmcg_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
+bool drmcg_try_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
size_t size);
void drmcg_unchg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
@@ -59,9 +62,10 @@ static inline void drmcg_device_early_init(struct drm_device *device)
{
}
-static inline void drmcg_chg_bo_alloc(struct drmcg *drmcg,
+static inline bool drmcg_try_chg_bo_alloc(struct drmcg *drmcg,
struct drm_device *dev, size_t size)
{
+ return true;
}
static inline void drmcg_unchg_bo_alloc(struct drmcg *drmcg,
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 9c588c329da0..ef073a5e7d67 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -352,7 +352,7 @@ void drm_gem_object_release(struct drm_gem_object *obj);
void drm_gem_object_free(struct kref *kref);
int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
-void drm_gem_private_object_init(struct drm_device *dev,
+bool drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
void drm_gem_vm_open(struct vm_area_struct *vma);
void drm_gem_vm_close(struct vm_area_struct *vma);
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 103868d972d0..71023654fb77 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -26,6 +26,7 @@ enum drmcg_res_type {
struct drmcg_device_resource {
/* for per device stats */
s64 bo_stats_total_allocated;
+ s64 bo_limits_total_allocated;
s64 bo_stats_peak_allocated;
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 5a700833a304..4b19e533941d 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -37,6 +37,8 @@ static void (*put_drm_dev)(struct drm_device *dev);
enum drmcg_file_type {
DRMCG_FTYPE_STATS,
+ DRMCG_FTYPE_LIMIT,
+ DRMCG_FTYPE_DEFAULT,
};
/**
@@ -90,6 +92,8 @@ static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
drmcg->dev_resources[minor] = ddr;
/* set defaults here */
+ ddr->bo_limits_total_allocated =
+ dev->drmcg_props.bo_limits_total_allocated_default;
return 0;
}
@@ -289,6 +293,38 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
}
}
+static void drmcg_print_limits(struct drmcg_device_resource *ddr,
+ struct seq_file *sf, enum drmcg_res_type type)
+{
+ if (ddr == NULL) {
+ seq_puts(sf, "\n");
+ return;
+ }
+
+ switch (type) {
+ case DRMCG_TYPE_BO_TOTAL:
+ seq_printf(sf, "%lld\n", ddr->bo_limits_total_allocated);
+ break;
+ default:
+ seq_puts(sf, "\n");
+ break;
+ }
+}
+
+static void drmcg_print_default(struct drmcg_props *props,
+ struct seq_file *sf, enum drmcg_res_type type)
+{
+ switch (type) {
+ case DRMCG_TYPE_BO_TOTAL:
+ seq_printf(sf, "%lld\n",
+ props->bo_limits_total_allocated_default);
+ break;
+ default:
+ seq_puts(sf, "\n");
+ break;
+ }
+}
+
static int drmcg_seq_show_fn(int id, void *ptr, void *data)
{
struct drm_minor *minor = ptr;
@@ -311,6 +347,12 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
case DRMCG_FTYPE_STATS:
drmcg_print_stats(ddr, sf, type);
break;
+ case DRMCG_FTYPE_LIMIT:
+ drmcg_print_limits(ddr, sf, type);
+ break;
+ case DRMCG_FTYPE_DEFAULT:
+ drmcg_print_default(&minor->dev->drmcg_props, sf, type);
+ break;
default:
seq_puts(sf, "\n");
break;
@@ -324,6 +366,130 @@ int drmcg_seq_show(struct seq_file *sf, void *v)
return drm_minor_for_each(&drmcg_seq_show_fn, sf);
}
+static void drmcg_pr_cft_err(const struct drmcg *drmcg,
+ int rc, const char *cft_name, int minor)
+{
+ pr_err("drmcg: error parsing %s, minor %d, rc %d ",
+ cft_name, minor, rc);
+ pr_cont_cgroup_name(drmcg->css.cgroup);
+ pr_cont("\n");
+}
+
+static int drmcg_process_limit_s64_val(char *sval, bool is_mem,
+ s64 def_val, s64 max_val, s64 *ret_val)
+{
+ int rc = strcmp("max", sval);
+
+
+ if (!rc)
+ *ret_val = max_val;
+ else {
+ rc = strcmp("default", sval);
+
+ if (!rc)
+ *ret_val = def_val;
+ }
+
+ if (rc) {
+ if (is_mem) {
+ *ret_val = memparse(sval, NULL);
+ rc = 0;
+ } else {
+ rc = kstrtoll(sval, 0, ret_val);
+ }
+ }
+
+ if (*ret_val > max_val)
+ rc = -EINVAL;
+
+ return rc;
+}
+
+/**
+ * drmcg_limit_write - parse cgroup interface files to obtain user config
+ *
+ * Minimal value check to keep track of user intent. For example, user
+ * can specify limits greater than the values allowed by the parents.
+ * This way, the user configuration is kept and comes into effect if and
+ * when parents' limits are relaxed.
+ */
+static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
+ size_t nbytes, loff_t off)
+{
+ struct drmcg *drmcg = css_to_drmcg(of_css(of));
+ enum drmcg_res_type type =
+ DRMCG_CTF_PRIV2RESTYPE(of_cft(of)->private);
+ char *cft_name = of_cft(of)->name;
+ char *limits = strstrip(buf);
+ struct drmcg_device_resource *ddr;
+ struct drmcg_props *props;
+ struct drm_minor *dm;
+ char *line;
+ char sattr[256];
+ s64 val;
+ int rc;
+ int minor;
+
+ while (limits != NULL) {
+ line = strsep(&limits, "\n");
+
+ if (sscanf(line,
+ __stringify(DRM_MAJOR)":%u %255[^\t\n]",
+ &minor, sattr) != 2) {
+ pr_err("drmcg: error parsing %s ", cft_name);
+ pr_cont_cgroup_name(drmcg->css.cgroup);
+ pr_cont("\n");
+
+ continue;
+ }
+
+ mutex_lock(&drmcg_mutex);
+ if (acquire_drm_minor)
+ dm = acquire_drm_minor(minor);
+ else
+ dm = NULL;
+ mutex_unlock(&drmcg_mutex);
+
+ if (IS_ERR_OR_NULL(dm)) {
+ pr_err("drmcg: invalid minor %d for %s ",
+ minor, cft_name);
+ pr_cont_cgroup_name(drmcg->css.cgroup);
+ pr_cont("\n");
+
+ continue;
+ }
+
+ mutex_lock(&dm->dev->drmcg_mutex);
+ ddr = drmcg->dev_resources[minor];
+ props = &dm->dev->drmcg_props;
+ switch (type) {
+ case DRMCG_TYPE_BO_TOTAL:
+ rc = drmcg_process_limit_s64_val(sattr, true,
+ props->bo_limits_total_allocated_default,
+ S64_MAX,
+ &val);
+
+ if (rc || val < 0) {
+ drmcg_pr_cft_err(drmcg, rc, cft_name, minor);
+ break;
+ }
+
+ ddr->bo_limits_total_allocated = val;
+ break;
+ default:
+ break;
+ }
+ mutex_unlock(&dm->dev->drmcg_mutex);
+
+ mutex_lock(&drmcg_mutex);
+ if (put_drm_dev)
+ put_drm_dev(dm->dev); /* release from acquire */
+ mutex_unlock(&drmcg_mutex);
+ }
+
+ return nbytes;
+}
+
struct cftype files[] = {
{
.name = "buffer.total.stats",
@@ -331,6 +497,20 @@ struct cftype files[] = {
.private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_TOTAL,
DRMCG_FTYPE_STATS),
},
+ {
+ .name = "buffer.total.default",
+ .seq_show = drmcg_seq_show,
+ .flags = CFTYPE_ONLY_ON_ROOT,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_TOTAL,
+ DRMCG_FTYPE_DEFAULT),
+ },
+ {
+ .name = "buffer.total.max",
+ .write = drmcg_limit_write,
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_TOTAL,
+ DRMCG_FTYPE_LIMIT),
+ },
{
.name = "buffer.peak.stats",
.seq_show = drmcg_seq_show,
@@ -363,12 +543,16 @@ struct cgroup_subsys gpu_cgrp_subsys = {
*/
void drmcg_device_early_init(struct drm_device *dev)
{
+ dev->drmcg_props.limit_enforced = false;
+
+ dev->drmcg_props.bo_limits_total_allocated_default = S64_MAX;
+
drmcg_update_cg_tree(dev);
}
EXPORT_SYMBOL(drmcg_device_early_init);
/**
- * drmcg_chg_bo_alloc - charge GEM buffer usage for a device and cgroup
+ * drmcg_try_chg_bo_alloc - charge GEM buffer usage for a device and cgroup
* @drmcg: the DRM cgroup to be charged to
* @dev: the device the usage should be charged to
* @size: size of the GEM buffer to be accounted for
@@ -377,29 +561,52 @@ EXPORT_SYMBOL(drmcg_device_early_init);
* for the utilization. This should not be called when the buffer is shared (
* the GEM buffer's reference count being incremented.)
*/
-void drmcg_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
+bool drmcg_try_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
size_t size)
{
struct drmcg_device_resource *ddr;
int devIdx = dev->primary->index;
+ struct drmcg_props *props = &dev->drmcg_props;
+ struct drmcg *drmcg_cur = drmcg;
+ bool result = true;
+ s64 delta = 0;
if (drmcg == NULL)
- return;
+ return true;
mutex_lock(&dev->drmcg_mutex);
- for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg)) {
- ddr = drmcg->dev_resources[devIdx];
+ if (props->limit_enforced) {
+ for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg)) {
+ ddr = drmcg->dev_resources[devIdx];
+ delta = ddr->bo_limits_total_allocated -
+ ddr->bo_stats_total_allocated;
+
+ if (delta <= 0 || size > delta) {
+ result = false;
+ break;
+ }
+ }
+ }
+
+ drmcg = drmcg_cur;
+
+ if (result || !props->limit_enforced) {
+ for ( ; drmcg != NULL; drmcg = drmcg_parent(drmcg)) {
+ ddr = drmcg->dev_resources[devIdx];
- ddr->bo_stats_total_allocated += (s64)size;
+ ddr->bo_stats_total_allocated += (s64)size;
- if (ddr->bo_stats_peak_allocated < (s64)size)
- ddr->bo_stats_peak_allocated = (s64)size;
+ if (ddr->bo_stats_peak_allocated < (s64)size)
+ ddr->bo_stats_peak_allocated = (s64)size;
- ddr->bo_stats_count_allocated++;
+ ddr->bo_stats_count_allocated++;
+ }
}
mutex_unlock(&dev->drmcg_mutex);
+
+ return result;
}
-EXPORT_SYMBOL(drmcg_chg_bo_alloc);
+EXPORT_SYMBOL(drmcg_try_chg_bo_alloc);
/**
* drmcg_unchg_bo_alloc -
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 08/11] drm, cgroup: Add peak GEM buffer allocation limit
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (6 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 07/11] drm, cgroup: Add total GEM buffer allocation limit Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 09/11] drm, cgroup: Add compute as gpu cgroup resource Kenny Ho
` (3 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
gpu.buffer.peak.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 largest GEM buffer allocation in bytes.
gpu.buffer.peak.max
A read-write flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Per device limits on the largest GEM buffer allocation in bytes.
This is a hard limit. Attempts in allocating beyond the cgroup
limit will result in ENOMEM. Shorthand understood by memparse
(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 <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 18 +++++++++++
include/drm/drm_cgroup.h | 1 +
include/linux/cgroup_drm.h | 1 +
kernel/cgroup/drm.c | 43 +++++++++++++++++++++++++
4 files changed, 63 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index f2d7abf5c783..581343472651 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2108,6 +2108,24 @@ GPU Interface Files
Set allocation limit for /dev/dri/card0 to 512MB
echo "226:0 512m" > gpu.buffer.total.max
+ gpu.buffer.peak.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 largest GEM buffer allocation in bytes.
+
+ gpu.buffer.peak.max
+ A read-write flat-keyed file which exists on all cgroups. Each
+ entry is keyed by the drm device's major:minor.
+
+ Per device limits on the largest GEM buffer allocation in bytes.
+ This is a hard limit. Attempts in allocating beyond the cgroup
+ limit will result in ENOMEM. Shorthand understood by memparse
+ (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
+
GEM Buffer Ownership
~~~~~~~~~~~~~~~~~~~~
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 2783e56690db..2b41d4d22e33 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -16,6 +16,7 @@ struct drmcg_props {
bool limit_enforced;
s64 bo_limits_total_allocated_default;
+ s64 bo_limits_peak_allocated_default;
};
void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 71023654fb77..aba3b26718c0 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -29,6 +29,7 @@ struct drmcg_device_resource {
s64 bo_limits_total_allocated;
s64 bo_stats_peak_allocated;
+ s64 bo_limits_peak_allocated;
s64 bo_stats_count_allocated;
};
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 4b19e533941d..62d2a9d33d0c 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -95,6 +95,9 @@ static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
ddr->bo_limits_total_allocated =
dev->drmcg_props.bo_limits_total_allocated_default;
+ ddr->bo_limits_peak_allocated =
+ dev->drmcg_props.bo_limits_peak_allocated_default;
+
return 0;
}
@@ -305,6 +308,9 @@ static void drmcg_print_limits(struct drmcg_device_resource *ddr,
case DRMCG_TYPE_BO_TOTAL:
seq_printf(sf, "%lld\n", ddr->bo_limits_total_allocated);
break;
+ case DRMCG_TYPE_BO_PEAK:
+ seq_printf(sf, "%lld\n", ddr->bo_limits_peak_allocated);
+ break;
default:
seq_puts(sf, "\n");
break;
@@ -319,6 +325,10 @@ static void drmcg_print_default(struct drmcg_props *props,
seq_printf(sf, "%lld\n",
props->bo_limits_total_allocated_default);
break;
+ case DRMCG_TYPE_BO_PEAK:
+ seq_printf(sf, "%lld\n",
+ props->bo_limits_peak_allocated_default);
+ break;
default:
seq_puts(sf, "\n");
break;
@@ -476,6 +486,19 @@ static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
ddr->bo_limits_total_allocated = val;
break;
+ case DRMCG_TYPE_BO_PEAK:
+ rc = drmcg_process_limit_s64_val(sattr, true,
+ props->bo_limits_peak_allocated_default,
+ S64_MAX,
+ &val);
+
+ if (rc || val < 0) {
+ drmcg_pr_cft_err(drmcg, rc, cft_name, minor);
+ break;
+ }
+
+ ddr->bo_limits_peak_allocated = val;
+ break;
default:
break;
}
@@ -517,6 +540,20 @@ struct cftype files[] = {
.private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_PEAK,
DRMCG_FTYPE_STATS),
},
+ {
+ .name = "buffer.peak.default",
+ .seq_show = drmcg_seq_show,
+ .flags = CFTYPE_ONLY_ON_ROOT,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_PEAK,
+ DRMCG_FTYPE_DEFAULT),
+ },
+ {
+ .name = "buffer.peak.max",
+ .write = drmcg_limit_write,
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_PEAK,
+ DRMCG_FTYPE_LIMIT),
+ },
{
.name = "buffer.count.stats",
.seq_show = drmcg_seq_show,
@@ -546,6 +583,7 @@ void drmcg_device_early_init(struct drm_device *dev)
dev->drmcg_props.limit_enforced = false;
dev->drmcg_props.bo_limits_total_allocated_default = S64_MAX;
+ dev->drmcg_props.bo_limits_peak_allocated_default = S64_MAX;
drmcg_update_cg_tree(dev);
}
@@ -585,6 +623,11 @@ bool drmcg_try_chg_bo_alloc(struct drmcg *drmcg, struct drm_device *dev,
result = false;
break;
}
+
+ if (ddr->bo_limits_peak_allocated < size) {
+ result = false;
+ break;
+ }
}
}
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 09/11] drm, cgroup: Add compute as gpu cgroup resource
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (7 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 08/11] drm, cgroup: Add peak " Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 10/11] drm, cgroup: add update trigger after limit change Kenny Ho
` (2 subsequent siblings)
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
gpu.compute.weight
A read-write flat-keyed file which exists on all cgroups. The
default weight is 100. Each entry is keyed by the DRM device's
major:minor (the primary minor). The weights are in the range [1,
10000] and specifies the relative amount of physical partitions
the cgroup can use in relation to its siblings. The partition
concept here is analogous to the subdevice of OpenCL.
gpu.compute.effective
A read-only nested-keyed file which exists on all cgroups. Each
entry is keyed by the DRM device's major:minor.
It lists the GPU subdevices that are actually granted to this
cgroup by its parent. These subdevices are allowed to be used by
tasks within the current cgroup.
===== ==============================================
count The total number of granted subdevices
list Enumeration of the subdevices
===== ==============================================
Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488
Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
---
Documentation/admin-guide/cgroup-v2.rst | 21 +++
include/drm/drm_cgroup.h | 3 +
include/linux/cgroup_drm.h | 16 +++
kernel/cgroup/drm.c | 177 +++++++++++++++++++++++-
4 files changed, 215 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 581343472651..f92f1f4a64d4 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2126,6 +2126,27 @@ GPU Interface Files
Set largest allocation for /dev/dri/card1 to 4MB
echo "226:1 4m" > gpu.buffer.peak.max
+ gpu.compute.weight
+ A read-write flat-keyed file which exists on all cgroups. The
+ default weight is 100. Each entry is keyed by the DRM device's
+ major:minor (the primary minor). The weights are in the range
+ [1, 10000] and specifies the relative amount of physical partitions
+ the cgroup can use in relation to its siblings. The partition
+ concept here is analogous to the subdevice concept of OpenCL.
+
+ gpu.compute.effective
+ A read-only nested-keyed file which exists on all cgroups.
+ Each entry is keyed by the DRM device's major:minor.
+
+ It lists the GPU subdevices that are actually granted to this
+ cgroup by its parent. These subdevices are allowed to be used
+ by tasks within the current cgroup.
+
+ ===== ==============================================
+ count The total number of granted subdevices
+ list Enumeration of the subdevices
+ ===== ==============================================
+
GEM Buffer Ownership
~~~~~~~~~~~~~~~~~~~~
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
index 2b41d4d22e33..5aac47ca536f 100644
--- a/include/drm/drm_cgroup.h
+++ b/include/drm/drm_cgroup.h
@@ -17,6 +17,9 @@ struct drmcg_props {
s64 bo_limits_total_allocated_default;
s64 bo_limits_peak_allocated_default;
+
+ int compute_capacity;
+ DECLARE_BITMAP(compute_slots, MAX_DRMCG_COMPUTE_CAPACITY);
};
void drmcg_bind(struct drm_minor (*(*acq_dm)(unsigned int minor_id)),
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index aba3b26718c0..fd02f59cabab 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -11,10 +11,14 @@
/* limit defined per the way drm_minor_alloc operates */
#define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
+#define MAX_DRMCG_COMPUTE_CAPACITY 256
+
enum drmcg_res_type {
DRMCG_TYPE_BO_TOTAL,
DRMCG_TYPE_BO_PEAK,
DRMCG_TYPE_BO_COUNT,
+ DRMCG_TYPE_COMPUTE,
+ DRMCG_TYPE_COMPUTE_EFF,
__DRMCG_TYPE_LAST,
};
@@ -32,6 +36,18 @@ struct drmcg_device_resource {
s64 bo_limits_peak_allocated;
s64 bo_stats_count_allocated;
+
+ /* compute_stg is used to calculate _eff before applying to _eff
+ * after considering the entire hierarchy
+ */
+ DECLARE_BITMAP(compute_stg, MAX_DRMCG_COMPUTE_CAPACITY);
+ /* user configurations */
+ s64 compute_weight;
+ /* effective compute for the cgroup after considering
+ * relationship with other cgroup
+ */
+ s64 compute_count_eff;
+ DECLARE_BITMAP(compute_eff, MAX_DRMCG_COMPUTE_CAPACITY);
};
/**
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 62d2a9d33d0c..2eadabebdfea 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -9,6 +9,7 @@
#include <linux/seq_file.h>
#include <linux/mutex.h>
#include <linux/kernel.h>
+#include <linux/bitmap.h>
#include <linux/cgroup_drm.h>
#include <drm/drm_file.h>
#include <drm/drm_drv.h>
@@ -98,6 +99,11 @@ static inline int init_drmcg_single(struct drmcg *drmcg, struct drm_device *dev)
ddr->bo_limits_peak_allocated =
dev->drmcg_props.bo_limits_peak_allocated_default;
+ bitmap_copy(ddr->compute_stg, dev->drmcg_props.compute_slots,
+ MAX_DRMCG_COMPUTE_CAPACITY);
+
+ ddr->compute_weight = CGROUP_WEIGHT_DFL;
+
return 0;
}
@@ -121,6 +127,104 @@ static inline void drmcg_update_cg_tree(struct drm_device *dev)
mutex_unlock(&cgroup_mutex);
}
+static void drmcg_calculate_effective_compute(struct drm_device *dev,
+ const unsigned long *free_weighted,
+ struct drmcg *parent_drmcg)
+{
+ int capacity = dev->drmcg_props.compute_capacity;
+ DECLARE_BITMAP(compute_unused, MAX_DRMCG_COMPUTE_CAPACITY);
+ DECLARE_BITMAP(compute_by_weight, MAX_DRMCG_COMPUTE_CAPACITY);
+ struct drmcg_device_resource *parent_ddr;
+ struct drmcg_device_resource *ddr;
+ int minor = dev->primary->index;
+ struct cgroup_subsys_state *pos;
+ struct drmcg *child;
+ s64 weight_sum = 0;
+ s64 unused;
+
+ parent_ddr = parent_drmcg->dev_resources[minor];
+
+ /* no static cfg, use weight for calculating the effective */
+ bitmap_copy(parent_ddr->compute_stg, free_weighted, capacity);
+
+ /* calculate compute available for dist by weight for children */
+ bitmap_copy(compute_unused, parent_ddr->compute_stg, capacity);
+ unused = bitmap_weight(compute_unused, capacity);
+ css_for_each_child(pos, &parent_drmcg->css) {
+ child = css_to_drmcg(pos);
+ ddr = child->dev_resources[minor];
+
+ /* no static allocation, participate in weight dist */
+ weight_sum += ddr->compute_weight;
+ }
+
+ css_for_each_child(pos, &parent_drmcg->css) {
+ int c;
+ int p = 0;
+ child = css_to_drmcg(pos);
+ ddr = child->dev_resources[minor];
+
+ bitmap_zero(compute_by_weight, capacity);
+ for (c = ddr->compute_weight * unused / weight_sum;
+ c > 0; c--) {
+ p = find_next_bit(compute_unused, capacity, p);
+ if (p < capacity) {
+ clear_bit(p, compute_unused);
+ set_bit(p, compute_by_weight);
+ }
+ }
+
+ drmcg_calculate_effective_compute(dev, compute_by_weight, child);
+ }
+}
+
+static void drmcg_apply_effective_compute(struct drm_device *dev)
+{
+ int capacity = dev->drmcg_props.compute_capacity;
+ int minor = dev->primary->index;
+ struct drmcg_device_resource *ddr;
+ struct cgroup_subsys_state *pos;
+ struct drmcg *drmcg;
+
+ if (root_drmcg == NULL) {
+ WARN_ON(root_drmcg == NULL);
+ return;
+ }
+
+ rcu_read_lock();
+
+ /* process the entire cgroup tree from root to simplify the algorithm */
+ drmcg_calculate_effective_compute(dev, dev->drmcg_props.compute_slots,
+ root_drmcg);
+
+ /* apply changes to effective only if there is a change */
+ css_for_each_descendant_pre(pos, &root_drmcg->css) {
+ drmcg = css_to_drmcg(pos);
+ ddr = drmcg->dev_resources[minor];
+
+ if (!bitmap_equal(ddr->compute_stg,
+ ddr->compute_eff, capacity)) {
+ bitmap_copy(ddr->compute_eff, ddr->compute_stg,
+ capacity);
+ ddr->compute_count_eff =
+ bitmap_weight(ddr->compute_eff, capacity);
+ }
+ }
+ rcu_read_unlock();
+}
+
+static void drmcg_apply_effective(enum drmcg_res_type type,
+ struct drm_device *dev, struct drmcg *changed_drmcg)
+{
+ switch (type) {
+ case DRMCG_TYPE_COMPUTE:
+ drmcg_apply_effective_compute(dev);
+ break;
+ default:
+ break;
+ }
+}
+
/**
* drmcg_register_dev - register a DRM device for usage in drm cgroup
* @dev: DRM device
@@ -143,7 +247,13 @@ void drmcg_register_dev(struct drm_device *dev)
{
dev->driver->drmcg_custom_init(dev, &dev->drmcg_props);
+ WARN_ON(dev->drmcg_props.compute_capacity !=
+ bitmap_weight(dev->drmcg_props.compute_slots,
+ MAX_DRMCG_COMPUTE_CAPACITY));
+
drmcg_update_cg_tree(dev);
+
+ drmcg_apply_effective(DRMCG_TYPE_COMPUTE, dev, root_drmcg);
}
mutex_unlock(&drmcg_mutex);
}
@@ -297,7 +407,8 @@ static void drmcg_print_stats(struct drmcg_device_resource *ddr,
}
static void drmcg_print_limits(struct drmcg_device_resource *ddr,
- struct seq_file *sf, enum drmcg_res_type type)
+ struct seq_file *sf, enum drmcg_res_type type,
+ struct drm_device *dev)
{
if (ddr == NULL) {
seq_puts(sf, "\n");
@@ -311,6 +422,17 @@ static void drmcg_print_limits(struct drmcg_device_resource *ddr,
case DRMCG_TYPE_BO_PEAK:
seq_printf(sf, "%lld\n", ddr->bo_limits_peak_allocated);
break;
+ case DRMCG_TYPE_COMPUTE:
+ seq_printf(sf, "%lld\n", ddr->compute_weight);
+ break;
+ case DRMCG_TYPE_COMPUTE_EFF:
+ seq_printf(sf, "%s=%lld %s=%*pbl\n",
+ "count",
+ ddr->compute_count_eff,
+ "list",
+ dev->drmcg_props.compute_capacity,
+ ddr->compute_eff);
+ break;
default:
seq_puts(sf, "\n");
break;
@@ -358,7 +480,7 @@ static int drmcg_seq_show_fn(int id, void *ptr, void *data)
drmcg_print_stats(ddr, sf, type);
break;
case DRMCG_FTYPE_LIMIT:
- drmcg_print_limits(ddr, sf, type);
+ drmcg_print_limits(ddr, sf, type, minor->dev);
break;
case DRMCG_FTYPE_DEFAULT:
drmcg_print_default(&minor->dev->drmcg_props, sf, type);
@@ -499,9 +621,25 @@ static ssize_t drmcg_limit_write(struct kernfs_open_file *of, char *buf,
ddr->bo_limits_peak_allocated = val;
break;
+ case DRMCG_TYPE_COMPUTE:
+ rc = drmcg_process_limit_s64_val(sattr, true,
+ CGROUP_WEIGHT_DFL, CGROUP_WEIGHT_MAX,
+ &val);
+
+ if (rc || val < CGROUP_WEIGHT_MIN ||
+ val > CGROUP_WEIGHT_MAX) {
+ drmcg_pr_cft_err(drmcg, rc, cft_name, minor);
+ break;
+ }
+
+ ddr->compute_weight = val;
+ break;
default:
break;
}
+
+ drmcg_apply_effective(type, dm->dev, drmcg);
+
mutex_unlock(&dm->dev->drmcg_mutex);
mutex_lock(&drmcg_mutex);
@@ -560,12 +698,44 @@ struct cftype files[] = {
.private = DRMCG_CTF_PRIV(DRMCG_TYPE_BO_COUNT,
DRMCG_FTYPE_STATS),
},
+ {
+ .name = "compute.weight",
+ .seq_show = drmcg_seq_show,
+ .write = drmcg_limit_write,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_COMPUTE,
+ DRMCG_FTYPE_LIMIT),
+ },
+ {
+ .name = "compute.effective",
+ .seq_show = drmcg_seq_show,
+ .private = DRMCG_CTF_PRIV(DRMCG_TYPE_COMPUTE_EFF,
+ DRMCG_FTYPE_LIMIT),
+ },
{ } /* terminate */
};
+static int drmcg_online_fn(int id, void *ptr, void *data)
+{
+ struct drm_minor *minor = ptr;
+ struct drmcg *drmcg = data;
+
+ if (minor->type != DRM_MINOR_PRIMARY)
+ return 0;
+
+ drmcg_apply_effective(DRMCG_TYPE_COMPUTE, minor->dev, drmcg);
+
+ return 0;
+}
+
+static int drmcg_css_online(struct cgroup_subsys_state *css)
+{
+ return drm_minor_for_each(&drmcg_online_fn, css_to_drmcg(css));
+}
+
struct cgroup_subsys gpu_cgrp_subsys = {
.css_alloc = drmcg_css_alloc,
.css_free = drmcg_css_free,
+ .css_online = drmcg_css_online,
.early_init = false,
.legacy_cftypes = files,
.dfl_cftypes = files,
@@ -585,6 +755,9 @@ void drmcg_device_early_init(struct drm_device *dev)
dev->drmcg_props.bo_limits_total_allocated_default = S64_MAX;
dev->drmcg_props.bo_limits_peak_allocated_default = S64_MAX;
+ dev->drmcg_props.compute_capacity = MAX_DRMCG_COMPUTE_CAPACITY;
+ bitmap_fill(dev->drmcg_props.compute_slots, MAX_DRMCG_COMPUTE_CAPACITY);
+
drmcg_update_cg_tree(dev);
}
EXPORT_SYMBOL(drmcg_device_early_init);
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 10/11] drm, cgroup: add update trigger after limit change
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (8 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 09/11] drm, cgroup: Add compute as gpu cgroup resource Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-02-26 19:01 ` [PATCH v2 11/11] drm/amdgpu: Integrate with DRM cgroup Kenny Ho
2020-03-17 16:03 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
Before this commit, drmcg limits are updated but enforcement is delayed
until the next time the driver check against the new limit. While this
is sufficient for certain resources, a more proactive enforcement may be
needed for other resources.
Introducing an optional drmcg_limit_updated callback for the DRM
drivers. When defined, it will be called in two scenarios:
1) When limits are updated for a particular cgroup, the callback will be
triggered for each task in the updated cgroup.
2) When a task is migrated from one cgroup to another, the callback will
be triggered for each resource type for the migrated task.
Change-Id: I0ce7c4e5a04c31bd0f8d9853a383575d4bc9a3fa
Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
---
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/drm/drm_drv.h
index 1f65ac4d9bbf..e7333143e722 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -724,6 +724,16 @@ struct drm_driver {
void (*drmcg_custom_init)(struct drm_device *dev,
struct drmcg_props *props);
+ /**
+ * @drmcg_limit_updated
+ *
+ * Optional callback
+ */
+ void (*drmcg_limit_updated)(struct drm_device *dev,
+ struct task_struct *task,
+ struct drmcg_device_resource *ddr,
+ enum drmcg_res_type res_type);
+
/**
* @gem_vm_ops: Driver private ops for this object
*
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 2eadabebdfea..da439a351b07 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -127,6 +127,26 @@ static inline void drmcg_update_cg_tree(struct drm_device *dev)
mutex_unlock(&cgroup_mutex);
}
+static void drmcg_limit_updated(struct drm_device *dev, struct drmcg *drmcg,
+ enum drmcg_res_type res_type)
+{
+ struct drmcg_device_resource *ddr =
+ drmcg->dev_resources[dev->primary->index];
+ struct css_task_iter it;
+ struct task_struct *task;
+
+ if (dev->driver->drmcg_limit_updated == NULL)
+ return;
+
+ css_task_iter_start(&drmcg->css.cgroup->self,
+ CSS_TASK_ITER_PROCS, &it);
+ while ((task = css_task_iter_next(&it))) {
+ dev->driver->drmcg_limit_updated(dev, task,
+ ddr, res_type);
+ }
+ css_task_iter_end(&it);
+}
+
static void drmcg_calculate_effective_compute(struct drm_device *dev,
const unsigned long *free_weighted,
struct drmcg *parent_drmcg)
@@ -208,6 +228,8 @@ static void drmcg_apply_effective_compute(struct drm_device *dev)
capacity);
ddr->compute_count_eff =
bitmap_weight(ddr->compute_eff, capacity);
+
+ drmcg_limit_updated(dev, drmcg, DRMCG_TYPE_COMPUTE);
}
}
rcu_read_unlock();
@@ -732,10 +754,46 @@ static int drmcg_css_online(struct cgroup_subsys_state *css)
return drm_minor_for_each(&drmcg_online_fn, css_to_drmcg(css));
}
+static int drmcg_attach_fn(int id, void *ptr, void *data)
+{
+ struct drm_minor *minor = ptr;
+ struct task_struct *task = data;
+ struct drm_device *dev;
+
+ if (minor->type != DRM_MINOR_PRIMARY)
+ return 0;
+
+ dev = minor->dev;
+
+ if (dev->driver->drmcg_limit_updated) {
+ struct drmcg *drmcg = drmcg_get(task);
+ struct drmcg_device_resource *ddr =
+ drmcg->dev_resources[minor->index];
+ enum drmcg_res_type type;
+
+ for (type = 0; type < __DRMCG_TYPE_LAST; type++)
+ dev->driver->drmcg_limit_updated(dev, task, ddr, type);
+
+ drmcg_put(drmcg);
+ }
+
+ return 0;
+}
+
+static void drmcg_attach(struct cgroup_taskset *tset)
+{
+ struct task_struct *task;
+ struct cgroup_subsys_state *css;
+
+ cgroup_taskset_for_each(task, css, tset)
+ drm_minor_for_each(&drmcg_attach_fn, task);
+}
+
struct cgroup_subsys gpu_cgrp_subsys = {
.css_alloc = drmcg_css_alloc,
.css_free = drmcg_css_free,
.css_online = drmcg_css_online,
+ .attach = drmcg_attach,
.early_init = false,
.legacy_cftypes = files,
.dfl_cftypes = files,
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH v2 11/11] drm/amdgpu: Integrate with DRM cgroup
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (9 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 10/11] drm, cgroup: add update trigger after limit change Kenny Ho
@ 2020-02-26 19:01 ` Kenny Ho
2020-03-17 16:03 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
11 siblings, 0 replies; 30+ messages in thread
From: Kenny Ho @ 2020-02-26 19:01 UTC (permalink / raw)
To: y2kenny, cgroups, dri-devel, amd-gfx, tj, alexander.deucher,
christian.koenig, felix.kuehling, joseph.greathouse, jsparks
Cc: Kenny Ho
The number of compute unit (CU) for a device is used for the gpu cgroup
compute capacity. The gpu cgroup compute allocation limit only applies
to compute workload for the moment (enforced via kfd queue creation.)
Any cu_mask update is validated against the availability of the compute
unit as defined by the drmcg the kfd process belongs to.
Change-Id: I2930e76ef9ac6d36d0feb81f604c89a4208e6614
Signed-off-by: Kenny Ho <Kenny.Ho@amd.com>
---
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 +
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +
.../amd/amdkfd/kfd_process_queue_manager.c | 153 ++++++++++++++++++
5 files changed, 196 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 0ee8aae6c519..1efbc0d3c03e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -199,6 +199,10 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev *dst, struct kgd_dev *s
valid; \
})
+int amdgpu_amdkfd_update_cu_mask_for_process(struct task_struct *task,
+ struct amdgpu_device *adev, unsigned long *compute_bm,
+ unsigned int compute_bm_size);
+
/* GPUVM API */
int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, unsigned int pasid,
void **vm, void **process_info,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 171397708855..595ad852080b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1418,9 +1418,31 @@ amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
static void amdgpu_drmcg_custom_init(struct drm_device *dev,
struct drmcg_props *props)
{
+ struct amdgpu_device *adev = dev->dev_private;
+
+ props->compute_capacity = adev->gfx.cu_info.number;
+ bitmap_zero(props->compute_slots, MAX_DRMCG_COMPUTE_CAPACITY);
+ bitmap_fill(props->compute_slots, props->compute_capacity);
+
props->limit_enforced = true;
}
+static void amdgpu_drmcg_limit_updated(struct drm_device *dev,
+ struct task_struct *task, struct drmcg_device_resource *ddr,
+ enum drmcg_res_type res_type)
+{
+ struct amdgpu_device *adev = dev->dev_private;
+
+ switch (res_type) {
+ case DRMCG_TYPE_COMPUTE:
+ amdgpu_amdkfd_update_cu_mask_for_process(task, adev,
+ ddr->compute_eff, dev->drmcg_props.compute_capacity);
+ break;
+ default:
+ break;
+ }
+}
+
#else
static void amdgpu_drmcg_custom_init(struct drm_device *dev,
@@ -1428,6 +1450,12 @@ static void amdgpu_drmcg_custom_init(struct drm_device *dev,
{
}
+static void amdgpu_drmcg_limit_updated(struct drm_device *dev,
+ struct task_struct *task, struct drmcg_device_resource *ddr,
+ enum drmcg_res_type res_type)
+{
+}
+
#endif /* CONFIG_CGROUP_DRM */
static struct drm_driver kms_driver = {
@@ -1462,6 +1490,7 @@ static struct drm_driver kms_driver = {
.gem_prime_mmap = amdgpu_gem_prime_mmap,
.drmcg_custom_init = amdgpu_drmcg_custom_init,
+ .drmcg_limit_updated = amdgpu_drmcg_limit_updated,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 675735b8243a..a35596f2dc4e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -451,6 +451,13 @@ static int kfd_ioctl_set_cu_mask(struct file *filp, struct kfd_process *p,
return -EFAULT;
}
+ if (!pqm_drmcg_compute_validate(p, args->queue_id,
+ properties.cu_mask, cu_mask_size)) {
+ pr_debug("CU mask not permitted by DRM Cgroup");
+ kfree(properties.cu_mask);
+ return -EACCES;
+ }
+
mutex_lock(&p->mutex);
retval = pqm_set_cu_mask(&p->pqm, args->queue_id, &properties);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 063096ec832d..0fb619586e24 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -929,6 +929,9 @@ int pqm_get_wave_state(struct process_queue_manager *pqm,
u32 *ctl_stack_used_size,
u32 *save_area_used_size);
+bool pqm_drmcg_compute_validate(struct kfd_process *p, int qid, u32 *cu_mask,
+ unsigned int cu_mask_size);
+
int amdkfd_fence_wait_timeout(unsigned int *fence_addr,
unsigned int fence_value,
unsigned int timeout_ms);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index cb1ca11b99c3..bd09403e07b5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -23,9 +23,11 @@
#include <linux/slab.h>
#include <linux/list.h>
+#include <linux/cgroup_drm.h>
#include "kfd_device_queue_manager.h"
#include "kfd_priv.h"
#include "kfd_kernel_queue.h"
+#include "amdgpu.h"
#include "amdgpu_amdkfd.h"
static inline struct process_queue_node *get_queue_by_qid(
@@ -167,6 +169,7 @@ static int init_user_queue(struct process_queue_manager *pqm,
struct queue_properties *q_properties,
struct file *f, unsigned int qid)
{
+ struct drmcg *drmcg;
int retval;
/* Doorbell initialized in user space*/
@@ -180,6 +183,37 @@ static int init_user_queue(struct process_queue_manager *pqm,
if (retval != 0)
return retval;
+#ifdef CONFIG_CGROUP_DRM
+ drmcg = drmcg_get(pqm->process->lead_thread);
+ if (drmcg) {
+ struct amdgpu_device *adev;
+ struct drmcg_device_resource *ddr;
+ int mask_size;
+ u32 *mask;
+
+ adev = (struct amdgpu_device *) dev->kgd;
+
+ mask_size = adev->ddev->drmcg_props.compute_capacity;
+ mask = kzalloc(sizeof(u32) * round_up(mask_size, 32),
+ GFP_KERNEL);
+
+ if (!mask) {
+ drmcg_put(drmcg);
+ uninit_queue(*q);
+ return -ENOMEM;
+ }
+
+ ddr = drmcg->dev_resources[adev->ddev->primary->index];
+
+ bitmap_to_arr32(mask, ddr->compute_eff, mask_size);
+
+ (*q)->properties.cu_mask_count = mask_size;
+ (*q)->properties.cu_mask = mask;
+
+ drmcg_put(drmcg);
+ }
+#endif /* CONFIG_CGROUP_DRM */
+
(*q)->device = dev;
(*q)->process = pqm->process;
@@ -510,6 +544,125 @@ int pqm_get_wave_state(struct process_queue_manager *pqm,
save_area_used_size);
}
+#ifdef CONFIG_CGROUP_DRM
+
+bool pqm_drmcg_compute_validate(struct kfd_process *p, int qid, u32 *cu_mask,
+ unsigned int cu_mask_size)
+{
+ DECLARE_BITMAP(curr_mask, MAX_DRMCG_COMPUTE_CAPACITY);
+ struct drmcg_device_resource *ddr;
+ struct process_queue_node *pqn;
+ struct amdgpu_device *adev;
+ struct drmcg *drmcg;
+ bool result;
+
+ if (cu_mask_size > MAX_DRMCG_COMPUTE_CAPACITY)
+ return false;
+
+ bitmap_from_arr32(curr_mask, cu_mask, cu_mask_size);
+
+ pqn = get_queue_by_qid(&p->pqm, qid);
+ if (!pqn)
+ return false;
+
+ adev = (struct amdgpu_device *)pqn->q->device->kgd;
+
+ drmcg = drmcg_get(p->lead_thread);
+ ddr = drmcg->dev_resources[adev->ddev->primary->index];
+
+ if (bitmap_subset(curr_mask, ddr->compute_eff,
+ MAX_DRMCG_COMPUTE_CAPACITY))
+ result = true;
+ else
+ result = false;
+
+ drmcg_put(drmcg);
+
+ return result;
+}
+
+#else
+
+bool pqm_drmcg_compute_validate(struct kfd_process *p, int qid, u32 *cu_mask,
+ unsigned int cu_mask_size)
+{
+ return true;
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+
+int amdgpu_amdkfd_update_cu_mask_for_process(struct task_struct *task,
+ struct amdgpu_device *adev, unsigned long *compute_bm,
+ unsigned int compute_bm_size)
+{
+ struct kfd_dev *kdev = adev->kfd.dev;
+ struct process_queue_node *pqn;
+ struct kfd_process *kfdproc;
+ size_t size_in_bytes;
+ u32 *cu_mask;
+ int rc = 0;
+
+ if ((compute_bm_size % 32) != 0) {
+ pr_warn("compute_bm_size %d must be a multiple of 32",
+ compute_bm_size);
+ return -EINVAL;
+ }
+
+ kfdproc = kfd_get_process(task);
+
+ if (IS_ERR(kfdproc))
+ return -ESRCH;
+
+ size_in_bytes = sizeof(u32) * round_up(compute_bm_size, 32);
+
+ mutex_lock(&kfdproc->mutex);
+ list_for_each_entry(pqn, &kfdproc->pqm.queues, process_queue_list) {
+ if (pqn->q && pqn->q->device == kdev) {
+ /* update cu_mask accordingly */
+ cu_mask = kzalloc(size_in_bytes, GFP_KERNEL);
+ if (!cu_mask) {
+ rc = -ENOMEM;
+ break;
+ }
+
+ if (pqn->q->properties.cu_mask) {
+ DECLARE_BITMAP(curr_mask,
+ MAX_DRMCG_COMPUTE_CAPACITY);
+
+ if (pqn->q->properties.cu_mask_count >
+ compute_bm_size) {
+ rc = -EINVAL;
+ kfree(cu_mask);
+ break;
+ }
+
+ bitmap_from_arr32(curr_mask,
+ pqn->q->properties.cu_mask,
+ pqn->q->properties.cu_mask_count);
+
+ bitmap_and(curr_mask, curr_mask, compute_bm,
+ compute_bm_size);
+
+ bitmap_to_arr32(cu_mask, curr_mask,
+ compute_bm_size);
+
+ kfree(curr_mask);
+ } else
+ bitmap_to_arr32(cu_mask, compute_bm,
+ compute_bm_size);
+
+ pqn->q->properties.cu_mask = cu_mask;
+ pqn->q->properties.cu_mask_count = compute_bm_size;
+
+ rc = pqn->q->device->dqm->ops.update_queue(
+ pqn->q->device->dqm, pqn->q);
+ }
+ }
+ mutex_unlock(&kfdproc->mutex);
+
+ return rc;
+}
+
#if defined(CONFIG_DEBUG_FS)
int pqm_debugfs_mqds(struct seq_file *m, void *data)
--
2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-02-26 19:01 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
` (10 preceding siblings ...)
2020-02-26 19:01 ` [PATCH v2 11/11] drm/amdgpu: Integrate with DRM cgroup Kenny Ho
@ 2020-03-17 16:03 ` Kenny Ho
2020-03-24 18:46 ` Tejun Heo
11 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-03-17 16:03 UTC (permalink / raw)
To: Kenny Ho, Tejun Heo
Cc: Kuehling, Felix, jsparks, amd-gfx list, dri-devel, Greathouse,
Joseph, Alex Deucher, cgroups, Christian König
Hi Tejun,
What's your thoughts on this latest series?
Regards,
Kenny
On Wed, Feb 26, 2020 at 2:02 PM Kenny Ho <Kenny.Ho@amd.com> wrote:
>
> This is a submission for the introduction of a new cgroup controller for the drm subsystem follow a series of RFCs [v1, v2, v3, v4]
>
> Changes from PR v1
> * changed cgroup controller name from drm to gpu
> * removed lgpu
> * added compute.weight resources, clarified resources being distributed as partitions of compute device
>
> PR v1: https://www.spinics.net/lists/cgroups/msg24479.html
>
> Changes from the RFC base on the feedbacks:
> * drop all drm.memory.* related implementation and focus only on buffer and lgpu
> * add weight resource type for logical gpu (lgpu)
> * uncoupled drmcg device iteration from drm_minor
>
> I'd also like to highlight the fact that these patches are currently released under MIT/X11 license aligning with the norm of the drm subsystem, but I am working to have the cgroup parts release under GPLv2 to align with the norm of the cgroup subsystem.
>
> RFC:
> [v1]: https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html
> [v2]: https://www.spinics.net/lists/cgroups/msg22074.html
> [v3]: https://lists.freedesktop.org/archives/amd-gfx/2019-June/036026.html
> [v4]: https://patchwork.kernel.org/cover/11120371/
>
> Changes since the start of RFC are as follows:
>
> v4:
> Unchanged (no review needed)
> * drm.memory.*/ttm resources (Patch 9-13, I am still working on memory bandwidth
> and shrinker)
> Base on feedbacks on v3:
> * update nominclature to drmcg
> * embed per device drmcg properties into drm_device
> * split GEM buffer related commits into stats and limit
> * rename function name to align with convention
> * combined buffer accounting and check into a try_charge function
> * support buffer stats without limit enforcement
> * removed GEM buffer sharing limitation
> * updated documentations
> New features:
> * introducing logical GPU concept
> * example implementation with AMD KFD
>
> v3:
> Base on feedbacks on v2:
> * removed .help type file from v2
> * conform to cgroup convention for default and max handling
> * conform to cgroup convention for addressing device specific limits (with major:minor)
> New function:
> * adopted memparse for memory size related attributes
> * added macro to marshall drmcgrp cftype private ?(DRMCG_CTF_PRIV, etc.)
> * added ttm buffer usage stats (per cgroup, for system, tt, vram.)
> * added ttm buffer usage limit (per cgroup, for vram.)
> * added per cgroup bandwidth stats and limiting (burst and average bandwidth)
>
> v2:
> * Removed the vendoring concepts
> * Add limit to total buffer allocation
> * Add limit to the maximum size of a buffer allocation
>
> v1: cover letter
>
> The purpose of this patch series is to start a discussion for a generic cgroup
> controller for the drm subsystem. The design proposed here is a very early
> one. We are hoping to engage the community as we develop the idea.
>
> Backgrounds
> ===========
> Control Groups/cgroup provide a mechanism for aggregating/partitioning sets of
> tasks, and all their future children, into hierarchical groups with specialized
> behaviour, such as accounting/limiting the resources which processes in a
> cgroup can access[1]. Weights, limits, protections, allocations are the main
> resource distribution models. Existing cgroup controllers includes cpu,
> memory, io, rdma, and more. cgroup is one of the foundational technologies
> that enables the popular container application deployment and management method.
>
> Direct Rendering Manager/drm contains code intended to support the needs of
> complex graphics devices. Graphics drivers in the kernel may make use of DRM
> functions to make tasks like memory management, interrupt handling and DMA
> easier, and provide a uniform interface to applications. The DRM has also
> developed beyond traditional graphics applications to support compute/GPGPU
> applications.
>
> Motivations
> ===========
> As GPU grow beyond the realm of desktop/workstation graphics into areas like
> data center clusters and IoT, there are increasing needs to monitor and
> regulate GPU as a resource like cpu, memory and io.
>
> Matt Roper from Intel began working on similar idea in early 2018 [2] for the
> purpose of managing GPU priority using the cgroup hierarchy. While that
> particular use case may not warrant a standalone drm cgroup controller, there
> are other use cases where having one can be useful [3]. Monitoring GPU
> resources such as VRAM and buffers, CU (compute unit [AMD's nomenclature])/EU
> (execution unit [Intel's nomenclature]), GPU job scheduling [4] can help
> sysadmins get a better understanding of the applications usage profile.
> Further usage regulations of the aforementioned resources can also help sysadmins
> optimize workload deployment on limited GPU resources.
>
> With the increased importance of machine learning, data science and other
> cloud-based applications, GPUs are already in production use in data centers
> today [5,6,7]. Existing GPU resource management is very course grain, however,
> as sysadmins are only able to distribute workload on a per-GPU basis [8]. An
> alternative is to use GPU virtualization (with or without SRIOV) but it
> generally acts on the entire GPU instead of the specific resources in a GPU.
> With a drm cgroup controller, we can enable alternate, fine-grain, sub-GPU
> resource management (in addition to what may be available via GPU
> virtualization.)
>
> In addition to production use, the DRM cgroup can also help with testing
> graphics application robustness by providing a mean to artificially limit DRM
> resources availble to the applications.
>
>
> Challenges
> ==========
> While there are common infrastructure in DRM that is shared across many vendors
> (the scheduler [4] for example), there are also aspects of DRM that are vendor
> specific. To accommodate this, we borrowed the mechanism used by the cgroup to
> handle different kinds of cgroup controller.
>
> Resources for DRM are also often device (GPU) specific instead of system
> specific and a system may contain more than one GPU. For this, we borrowed
> some of the ideas from RDMA cgroup controller.
>
> Approach
> ========
> To experiment with the idea of a DRM cgroup, we would like to start with basic
> accounting and statistics, then continue to iterate and add regulating
> mechanisms into the driver.
>
> [1] https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
> [2] https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
> [3] https://www.spinics.net/lists/cgroups/msg20720.html
> [4] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/scheduler
> [5] https://kubernetes.io/docs/tasks/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 (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 allocation stats
> drm, cgroup: Add GEM buffer allocation count stats
> drm, cgroup: Add total GEM buffer allocation limit
> drm, cgroup: Add peak GEM buffer allocation limit
> drm, cgroup: Add compute as gpu cgroup resource
> drm, cgroup: add update trigger after limit change
> drm/amdgpu: Integrate with DRM cgroup
>
> Documentation/admin-guide/cgroup-v2.rst | 138 ++-
> Documentation/cgroup-v1/drm.rst | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 48 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 7 +
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +
> .../amd/amdkfd/kfd_process_queue_manager.c | 153 +++
> drivers/gpu/drm/drm_drv.c | 12 +
> drivers/gpu/drm/drm_gem.c | 16 +-
> include/drm/drm_cgroup.h | 81 ++
> include/drm/drm_device.h | 7 +
> include/drm/drm_drv.h | 19 +
> include/drm/drm_gem.h | 12 +-
> include/linux/cgroup_drm.h | 138 +++
> include/linux/cgroup_subsys.h | 4 +
> init/Kconfig | 5 +
> kernel/cgroup/Makefile | 1 +
> kernel/cgroup/drm.c | 913 ++++++++++++++++++
> 19 files changed, 1563 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/cgroup-v1/drm.rst
> create mode 100644 include/drm/drm_cgroup.h
> create mode 100644 include/linux/cgroup_drm.h
> create mode 100644 kernel/cgroup/drm.c
>
> --
> 2.25.0
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-03-17 16:03 ` [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Kenny Ho
@ 2020-03-24 18:46 ` Tejun Heo
2020-03-24 18:49 ` Kenny Ho
0 siblings, 1 reply; 30+ messages in thread
From: Tejun Heo @ 2020-03-24 18:46 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, dri-devel,
Greathouse, Joseph, Alex Deucher, cgroups, Christian König
On Tue, Mar 17, 2020 at 12:03:20PM -0400, Kenny Ho wrote:
> What's your thoughts on this latest series?
My overall impression is that the feedbacks aren't being incorporated throughly
/ sufficiently.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-03-24 18:46 ` Tejun Heo
@ 2020-03-24 18:49 ` Kenny Ho
2020-04-13 19:11 ` Tejun Heo
0 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-03-24 18:49 UTC (permalink / raw)
To: Tejun Heo
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, dri-devel,
Greathouse, Joseph, Alex Deucher, cgroups, Christian König
Hi Tejun,
Can you elaborate more on what are the missing pieces?
Regards,
Kenny
On Tue, Mar 24, 2020 at 2:46 PM Tejun Heo <tj@kernel.org> wrote:
>
> On Tue, Mar 17, 2020 at 12:03:20PM -0400, Kenny Ho wrote:
> > What's your thoughts on this latest series?
>
> My overall impression is that the feedbacks aren't being incorporated throughly
> / sufficiently.
>
> Thanks.
>
> --
> tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-03-24 18:49 ` Kenny Ho
@ 2020-04-13 19:11 ` Tejun Heo
2020-04-13 20:12 ` Ho, Kenny
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Tejun Heo @ 2020-04-13 19:11 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, dri-devel,
Greathouse, Joseph, Alex Deucher, cgroups, Christian König
Hello, Kenny.
On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> Can you elaborate more on what are the missing pieces?
Sorry about the long delay, but I think we've been going in circles for quite
a while now. Let's try to make it really simple as the first step. How about
something like the following?
* gpu.weight (should it be gpu.compute.weight? idk) - A single number
per-device weight similar to io.weight, which distributes computation
resources in work-conserving way.
* gpu.memory.high - A single number per-device on-device memory limit.
The above two, if works well, should already be plenty useful. And my guess is
that getting the above working well will be plenty challenging already even
though it's already excluding work-conserving memory distribution. So, let's
please do that as the first step and see what more would be needed from there.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-13 19:11 ` Tejun Heo
@ 2020-04-13 20:12 ` Ho, Kenny
2020-04-13 20:17 ` Kenny Ho
2020-04-14 12:20 ` Daniel Vetter
2 siblings, 0 replies; 30+ messages in thread
From: Ho, Kenny @ 2020-04-13 20:12 UTC (permalink / raw)
To: Tejun Heo, Kenny Ho
Cc: Kuehling, Felix, jsparks, amd-gfx list, Larry Kaplan, dri-devel,
Greathouse, Joseph, Deucher, Alexander, cgroups, Koenig,
Christian
[-- Attachment #1.1: Type: text/plain, Size: 3210 bytes --]
[AMD Official Use Only - Internal Distribution Only]
Hi Tejun,
Thanks for taking the time to reply.
Perhaps we can even narrow things down to just gpu.weight/gpu.compute.weight as a start? In this aspect, is the key objection to the current implementation of gpu.compute.weight the work-conserving bit? This work-conserving requirement is probably what I have missed for the last two years (and hence going in circle.)
If this is the case, can you clarify/confirm the followings?
1) Is resource scheduling goal of cgroup purely for the purpose of throughput? (at the expense of other scheduling goals such as latency.)
2) If 1) is true, under what circumstances will the "Allocations" resource distribution model (as defined in the cgroup-v2) be acceptable?
3) If 1) is true, are things like cpuset from cgroup v1 no longer acceptable going forward?
To be clear, while some have framed this (time sharing vs spatial sharing) as a partisan issue, it is in fact a technical one. I have implemented the gpu cgroup support this way because we have a class of users that value low latency/low jitter/predictability/synchronicity. For example, they would like 4 tasks to share a GPU and they would like the tasks to start and finish at the same time.
What is the rationale behind picking the Weight model over Allocations as the first acceptable implementation? Can't we have both work-conserving and non-work-conserving ways of distributing GPU resources? If we can, why not allow non-work-conserving implementation first, especially when we have users asking for such functionality?
Regards,
Kenny
________________________________
From: Tejun Heo <htejun@gmail.com> on behalf of Tejun Heo <tj@kernel.org>
Sent: Monday, April 13, 2020 3:11 PM
To: Kenny Ho <y2kenny@gmail.com>
Cc: Ho, Kenny <Kenny.Ho@amd.com>; cgroups@vger.kernel.org <cgroups@vger.kernel.org>; dri-devel <dri-devel@lists.freedesktop.org>; amd-gfx list <amd-gfx@lists.freedesktop.org>; Deucher, Alexander <Alexander.Deucher@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; Kuehling, Felix <Felix.Kuehling@amd.com>; Greathouse, Joseph <Joseph.Greathouse@amd.com>; jsparks@cray.com <jsparks@cray.com>
Subject: Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hello, Kenny.
On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> Can you elaborate more on what are the missing pieces?
Sorry about the long delay, but I think we've been going in circles for quite
a while now. Let's try to make it really simple as the first step. How about
something like the following?
* gpu.weight (should it be gpu.compute.weight? idk) - A single number
per-device weight similar to io.weight, which distributes computation
resources in work-conserving way.
* gpu.memory.high - A single number per-device on-device memory limit.
The above two, if works well, should already be plenty useful. And my guess is
that getting the above working well will be plenty challenging already even
though it's already excluding work-conserving memory distribution. So, let's
please do that as the first step and see what more would be needed from there.
Thanks.
--
tejun
[-- Attachment #1.2: Type: text/html, Size: 6664 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-13 19:11 ` Tejun Heo
2020-04-13 20:12 ` Ho, Kenny
@ 2020-04-13 20:17 ` Kenny Ho
2020-04-13 20:54 ` Tejun Heo
2020-04-14 12:20 ` Daniel Vetter
2 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-04-13 20:17 UTC (permalink / raw)
To: Tejun Heo
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, lkaplan,
dri-devel, Greathouse, Joseph, Alex Deucher, cgroups,
Christian König
(replying again in plain-text)
Hi Tejun,
Thanks for taking the time to reply.
Perhaps we can even narrow things down to just
gpu.weight/gpu.compute.weight as a start? In this aspect, is the key
objection to the current implementation of gpu.compute.weight the
work-conserving bit? This work-conserving requirement is probably
what I have missed for the last two years (and hence going in circle.)
If this is the case, can you clarify/confirm the followings?
1) Is resource scheduling goal of cgroup purely for the purpose of
throughput? (at the expense of other scheduling goals such as
latency.)
2) If 1) is true, under what circumstances will the "Allocations"
resource distribution model (as defined in the cgroup-v2) be
acceptable?
3) If 1) is true, are things like cpuset from cgroup v1 no longer
acceptable going forward?
To be clear, while some have framed this (time sharing vs spatial
sharing) as a partisan issue, it is in fact a technical one. I have
implemented the gpu cgroup support this way because we have a class of
users that value low latency/low jitter/predictability/synchronicity.
For example, they would like 4 tasks to share a GPU and they would
like the tasks to start and finish at the same time.
What is the rationale behind picking the Weight model over Allocations
as the first acceptable implementation? Can't we have both
work-conserving and non-work-conserving ways of distributing GPU
resources? If we can, why not allow non-work-conserving
implementation first, especially when we have users asking for such
functionality?
Regards,
Kenny
On Mon, Apr 13, 2020 at 3:11 PM Tejun Heo <tj@kernel.org> wrote:
>
> Hello, Kenny.
>
> On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> > Can you elaborate more on what are the missing pieces?
>
> Sorry about the long delay, but I think we've been going in circles for quite
> a while now. Let's try to make it really simple as the first step. How about
> something like the following?
>
> * gpu.weight (should it be gpu.compute.weight? idk) - A single number
> per-device weight similar to io.weight, which distributes computation
> resources in work-conserving way.
>
> * gpu.memory.high - A single number per-device on-device memory limit.
>
> The above two, if works well, should already be plenty useful. And my guess is
> that getting the above working well will be plenty challenging already even
> though it's already excluding work-conserving memory distribution. So, let's
> please do that as the first step and see what more would be needed from there.
>
> Thanks.
>
> --
> tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-13 20:17 ` Kenny Ho
@ 2020-04-13 20:54 ` Tejun Heo
2020-04-13 21:40 ` Kenny Ho
0 siblings, 1 reply; 30+ messages in thread
From: Tejun Heo @ 2020-04-13 20:54 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, lkaplan,
dri-devel, Greathouse, Joseph, Alex Deucher, cgroups,
Christian König
Hello,
On Mon, Apr 13, 2020 at 04:17:14PM -0400, Kenny Ho wrote:
> Perhaps we can even narrow things down to just
> gpu.weight/gpu.compute.weight as a start? In this aspect, is the key
That sounds great to me.
> objection to the current implementation of gpu.compute.weight the
> work-conserving bit? This work-conserving requirement is probably
> what I have missed for the last two years (and hence going in circle.)
>
> If this is the case, can you clarify/confirm the followings?
>
> 1) Is resource scheduling goal of cgroup purely for the purpose of
> throughput? (at the expense of other scheduling goals such as
> latency.)
It's not; however, work-conserving mechanisms are the easiest to use (cuz you
don't lose anything) while usually challenging to implement. It tends to
clarify how control mechanisms should be structured - even what resources are.
> 2) If 1) is true, under what circumstances will the "Allocations"
> resource distribution model (as defined in the cgroup-v2) be
> acceptable?
Allocations definitely are acceptable and it's not a pre-requisite to have
work-conserving control first either. Here, given the lack of consensus in
terms of what even constitute resource units, I don't think it'd be a good
idea to commit to the proposed interface and believe it'd be beneficial to
work on interface-wise simpler work conserving controls.
> 3) If 1) is true, are things like cpuset from cgroup v1 no longer
> acceptable going forward?
Again, they're acceptable.
> To be clear, while some have framed this (time sharing vs spatial
> sharing) as a partisan issue, it is in fact a technical one. I have
> implemented the gpu cgroup support this way because we have a class of
> users that value low latency/low jitter/predictability/synchronicity.
> For example, they would like 4 tasks to share a GPU and they would
> like the tasks to start and finish at the same time.
>
> What is the rationale behind picking the Weight model over Allocations
> as the first acceptable implementation? Can't we have both
> work-conserving and non-work-conserving ways of distributing GPU
> resources? If we can, why not allow non-work-conserving
> implementation first, especially when we have users asking for such
> functionality?
I hope the rationales are clear now. What I'm objecting is inclusion of
premature interface, which is a lot easier and more tempting to do for
hardware-specific limits and the proposals up until now have been showing
ample signs of that. I don't think my position has changed much since the
beginning - do the difficult-to-implement but easy-to-use weights first and
then you and everyone would have a better idea of what hard-limit or
allocation interfaces and mechanisms should look like, or even whether they're
needed.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-13 20:54 ` Tejun Heo
@ 2020-04-13 21:40 ` Kenny Ho
2020-04-13 21:53 ` Tejun Heo
0 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-04-13 21:40 UTC (permalink / raw)
To: Tejun Heo
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, lkaplan,
dri-devel, Greathouse, Joseph, Alex Deucher, cgroups,
Christian König
Hi,
On Mon, Apr 13, 2020 at 4:54 PM Tejun Heo <tj@kernel.org> wrote:
>
> Allocations definitely are acceptable and it's not a pre-requisite to have
> work-conserving control first either. Here, given the lack of consensus in
> terms of what even constitute resource units, I don't think it'd be a good
> idea to commit to the proposed interface and believe it'd be beneficial to
> work on interface-wise simpler work conserving controls.
>
...
> I hope the rationales are clear now. What I'm objecting is inclusion of
> premature interface, which is a lot easier and more tempting to do for
> hardware-specific limits and the proposals up until now have been showing
> ample signs of that. I don't think my position has changed much since the
> beginning - do the difficult-to-implement but easy-to-use weights first and
> then you and everyone would have a better idea of what hard-limit or
> allocation interfaces and mechanisms should look like, or even whether they're
> needed.
By lack of consense, do you mean Intel's assertion that a standard is
not a standard until Intel implements it? (That was in the context of
OpenCL language standard with the concept of SubDevice.) I thought
the discussion so far has established that the concept of a compute
unit, while named differently (AMD's CUs, ARM's SCs, Intel's EUs,
Nvidia's SMs, Qualcomm's SPs), is cross vendor. While an AMD CU is
not the same as an Intel EU or Nvidia SM, the same can be said for CPU
cores. If cpuset is acceptable for a diversity of CPU core designs
and arrangements, I don't understand why an interface derived from GPU
SubDevice is considered premature.
If a decade-old language standard is not considered a consenses, can
you elaborate on what might consitute a consenses?
Regards,
Kenny
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-13 21:40 ` Kenny Ho
@ 2020-04-13 21:53 ` Tejun Heo
0 siblings, 0 replies; 30+ messages in thread
From: Tejun Heo @ 2020-04-13 21:53 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, amd-gfx list, lkaplan,
dri-devel, Greathouse, Joseph, Alex Deucher, cgroups,
Christian König
Hello,
On Mon, Apr 13, 2020 at 05:40:32PM -0400, Kenny Ho wrote:
> By lack of consense, do you mean Intel's assertion that a standard is
> not a standard until Intel implements it? (That was in the context of
> OpenCL language standard with the concept of SubDevice.) I thought
> the discussion so far has established that the concept of a compute
> unit, while named differently (AMD's CUs, ARM's SCs, Intel's EUs,
> Nvidia's SMs, Qualcomm's SPs), is cross vendor. While an AMD CU is
> not the same as an Intel EU or Nvidia SM, the same can be said for CPU
> cores. If cpuset is acceptable for a diversity of CPU core designs
> and arrangements, I don't understand why an interface derived from GPU
> SubDevice is considered premature.
CPUs are a lot more uniform across vendors than GPUs and have way higher user
observability and awareness. And, even then, it's something which has limited
usefulness because the configuration is inherently more complex involving
topology details and the end result is not work-conserving.
cpuset is there partly due to historical reasons and its features can often be
trivially replicated with some scripting around taskset. If that's all you're
trying to add, I don't see why it needs to be in cgroup at all. Just implement
a tool similar to taskset and build sufficient tooling around it. Given how
hardware specific it can become, that is likely the better direction anyway.
Thanks.
--
tejun
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-13 19:11 ` Tejun Heo
2020-04-13 20:12 ` Ho, Kenny
2020-04-13 20:17 ` Kenny Ho
@ 2020-04-14 12:20 ` Daniel Vetter
2020-04-14 12:47 ` Kenny Ho
2 siblings, 1 reply; 30+ messages in thread
From: Daniel Vetter @ 2020-04-14 12:20 UTC (permalink / raw)
To: Tejun Heo
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, Kenny Ho,
amd-gfx list, Greathouse, Joseph, Alex Deucher, cgroups,
Christian König
On Mon, Apr 13, 2020 at 03:11:36PM -0400, Tejun Heo wrote:
> Hello, Kenny.
>
> On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote:
> > Can you elaborate more on what are the missing pieces?
>
> Sorry about the long delay, but I think we've been going in circles for quite
> a while now. Let's try to make it really simple as the first step. How about
> something like the following?
>
> * gpu.weight (should it be gpu.compute.weight? idk) - A single number
> per-device weight similar to io.weight, which distributes computation
> resources in work-conserving way.
>
> * gpu.memory.high - A single number per-device on-device memory limit.
>
> The above two, if works well, should already be plenty useful. And my guess is
> that getting the above working well will be plenty challenging already even
> though it's already excluding work-conserving memory distribution. So, let's
> please do that as the first step and see what more would be needed from there.
This agrees with my understanding of the consensus here and what's
reasonable possible across different gpus. And in case this isn't clear:
This is very much me talking with my drm co-maintainer hat on, not with a
gpu vendor hat on (since that's implied somewhere further down the
discussion). My understanding from talking with a few other folks is that
the cpumask-style CU-weight thing is not something any other gpu can
reasonably support (and we have about 6+ of those in-tree), whereas some
work-preserving computation resource thing should be doable for anyone
with a scheduler. +/- more or less the same issues as io devices, there
might be quite bit latencies involved from going from one client to the
other because gpu pipelines are deed and pre-emption for gpus rather slow.
And ofc not all gpu "requests" use equal amounts of resources (different
engines and stuff just to begin with), same way not all io requests are
made equal. Plus since we do have a shared scheduler used by at least most
drivers, this shouldn't be too hard to get done somewhat consistently
across drivers
tldr; Acked by me.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 12:20 ` Daniel Vetter
@ 2020-04-14 12:47 ` Kenny Ho
2020-04-14 12:52 ` Daniel Vetter
0 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-04-14 12:47 UTC (permalink / raw)
To: Daniel Vetter
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
Hi Daniel,
On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> My understanding from talking with a few other folks is that
> the cpumask-style CU-weight thing is not something any other gpu can
> reasonably support (and we have about 6+ of those in-tree)
How does Intel plan to support the SubDevice API as described in your
own spec here:
https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
Regards,
Kenny
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 12:47 ` Kenny Ho
@ 2020-04-14 12:52 ` Daniel Vetter
2020-04-14 13:14 ` Kenny Ho
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Vetter @ 2020-04-14 12:52 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > My understanding from talking with a few other folks is that
> > the cpumask-style CU-weight thing is not something any other gpu can
> > reasonably support (and we have about 6+ of those in-tree)
>
> How does Intel plan to support the SubDevice API as described in your
> own spec here:
> https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
I can't talk about whether future products might or might not support
stuff and in what form exactly they might support stuff or not support
stuff. Or why exactly that's even in the spec there or not.
Geez
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 12:52 ` Daniel Vetter
@ 2020-04-14 13:14 ` Kenny Ho
2020-04-14 13:26 ` Daniel Vetter
0 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-04-14 13:14 UTC (permalink / raw)
To: Daniel Vetter
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
Ok. I was hoping you can clarify the contradiction between the
existance of the spec below and your "not something any other gpu can
reasonably support" statement. I mean, OneAPI is Intel's spec and
doesn't that at least make SubDevice support "reasonable" for one more
vendor?
Partisanship aside, as a drm co-maintainer, do you really not see the
need for non-work-conserving way of distributing GPU as a resource?
You recognized the latencies involved (although that's really just
part of the story... time sharing is never going to be good enough
even if your switching cost is zero.) As a drm co-maintainer, are you
suggesting GPU has no place in the HPC use case?
Regards,
Kenny
On Tue, Apr 14, 2020 at 8:52 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > My understanding from talking with a few other folks is that
> > > the cpumask-style CU-weight thing is not something any other gpu can
> > > reasonably support (and we have about 6+ of those in-tree)
> >
> > How does Intel plan to support the SubDevice API as described in your
> > own spec here:
> > https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
>
> I can't talk about whether future products might or might not support
> stuff and in what form exactly they might support stuff or not support
> stuff. Or why exactly that's even in the spec there or not.
>
> Geez
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 13:14 ` Kenny Ho
@ 2020-04-14 13:26 ` Daniel Vetter
2020-04-14 13:50 ` Kenny Ho
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Vetter @ 2020-04-14 13:26 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
On Tue, Apr 14, 2020 at 3:14 PM Kenny Ho <y2kenny@gmail.com> wrote:
>
> Ok. I was hoping you can clarify the contradiction between the
> existance of the spec below and your "not something any other gpu can
> reasonably support" statement. I mean, OneAPI is Intel's spec and
> doesn't that at least make SubDevice support "reasonable" for one more
> vendor?
>
> Partisanship aside, as a drm co-maintainer, do you really not see the
> need for non-work-conserving way of distributing GPU as a resource?
> You recognized the latencies involved (although that's really just
> part of the story... time sharing is never going to be good enough
> even if your switching cost is zero.) As a drm co-maintainer, are you
> suggesting GPU has no place in the HPC use case?
So I did chat with people and my understanding for how this subdevice
stuff works is roughly, from least to most fine grained support:
- Not possible at all, hw doesn't have any such support
- The hw is actually not a single gpu, but a bunch of chips behind a
magic bridge/interconnect, and there's a scheduler load-balancing
stuff and you can't actually run on all "cores" in parallel with one
compute/3d job. So subdevices just give you some of these cores, but
from client api pov they're exactly as powerful as the full device. So
this kinda works like assigning an entire NUMA node, including all the
cpu cores and memory bandwidth and everything.
- Hw has multiple "engines" which share resources (like compute cores
or whatever) behind the scenes. There's no control over how this
sharing works really, and whether you have guarantees about minimal
execution resources or not. This kinda works like hyperthreading.
- Then finally we have the CU mask thing amdgpu has. Which works like
what you're proposing, works on amd.
So this isn't something that I think we should standardize in a
resource management framework like cgroups. Because it's a complete
mess. Note that _all_ the above things (including the "no subdevices"
one) are valid implementations of "subdevices" in the various specs.
Now on your question on "why was this added to various standards?"
because opencl has that too (and the rocm thing, and everything else
it seems). What I heard is that a few people pushed really hard, and
no one objected hard enough (because not having subdevices is a
standards compliant implementation), so that's why it happened. Just
because it's in various standards doesn't mean that a) it's actually
standardized in a useful fashion and b) something we should just
blindly adopt.
Also like where exactly did you understand that I'm against gpus in
HPC uses cases. Approaching this in a slightly less tribal way would
really, really help to get something landed (which I'd like to see
happen, personally). Always spinning this as an Intel vs AMD thing
like you do here with every reply really doesn't help moving this in.
So yeah stricter isolation is something customers want, it's just not
something we can really give out right now at a level below the
device.
-Daniel
>
> Regards,
> Kenny
>
> On Tue, Apr 14, 2020 at 8:52 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > My understanding from talking with a few other folks is that
> > > > the cpumask-style CU-weight thing is not something any other gpu can
> > > > reasonably support (and we have about 6+ of those in-tree)
> > >
> > > How does Intel plan to support the SubDevice API as described in your
> > > own spec here:
> > > https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
> >
> > I can't talk about whether future products might or might not support
> > stuff and in what form exactly they might support stuff or not support
> > stuff. Or why exactly that's even in the spec there or not.
> >
> > Geez
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 13:26 ` Daniel Vetter
@ 2020-04-14 13:50 ` Kenny Ho
2020-04-14 14:04 ` Daniel Vetter
0 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-04-14 13:50 UTC (permalink / raw)
To: Daniel Vetter
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
Hi Daniel,
I appreciate many of your review so far and I much prefer keeping
things technical but that is very difficult to do when I get Intel
developers calling my implementation "most AMD-specific solution
possible" and objecting to an implementation because their hardware
cannot support it. Can you help me with a more charitable
interpretation of what has been happening?
Perhaps the following questions can help keep the discussion technical:
1) Is it possible to implement non-work-conserving distribution of
GPU without spatial sharing? (If yes, I'd love to hear a suggestion,
if not...question 2.)
2) If spatial sharing is required to support GPU HPC use cases, what
would you implement if you have the hardware support today?
Regards,
Kenny
On Tue, Apr 14, 2020 at 9:26 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, Apr 14, 2020 at 3:14 PM Kenny Ho <y2kenny@gmail.com> wrote:
> >
> > Ok. I was hoping you can clarify the contradiction between the
> > existance of the spec below and your "not something any other gpu can
> > reasonably support" statement. I mean, OneAPI is Intel's spec and
> > doesn't that at least make SubDevice support "reasonable" for one more
> > vendor?
> >
> > Partisanship aside, as a drm co-maintainer, do you really not see the
> > need for non-work-conserving way of distributing GPU as a resource?
> > You recognized the latencies involved (although that's really just
> > part of the story... time sharing is never going to be good enough
> > even if your switching cost is zero.) As a drm co-maintainer, are you
> > suggesting GPU has no place in the HPC use case?
>
> So I did chat with people and my understanding for how this subdevice
> stuff works is roughly, from least to most fine grained support:
> - Not possible at all, hw doesn't have any such support
> - The hw is actually not a single gpu, but a bunch of chips behind a
> magic bridge/interconnect, and there's a scheduler load-balancing
> stuff and you can't actually run on all "cores" in parallel with one
> compute/3d job. So subdevices just give you some of these cores, but
> from client api pov they're exactly as powerful as the full device. So
> this kinda works like assigning an entire NUMA node, including all the
> cpu cores and memory bandwidth and everything.
> - Hw has multiple "engines" which share resources (like compute cores
> or whatever) behind the scenes. There's no control over how this
> sharing works really, and whether you have guarantees about minimal
> execution resources or not. This kinda works like hyperthreading.
> - Then finally we have the CU mask thing amdgpu has. Which works like
> what you're proposing, works on amd.
>
> So this isn't something that I think we should standardize in a
> resource management framework like cgroups. Because it's a complete
> mess. Note that _all_ the above things (including the "no subdevices"
> one) are valid implementations of "subdevices" in the various specs.
>
> Now on your question on "why was this added to various standards?"
> because opencl has that too (and the rocm thing, and everything else
> it seems). What I heard is that a few people pushed really hard, and
> no one objected hard enough (because not having subdevices is a
> standards compliant implementation), so that's why it happened. Just
> because it's in various standards doesn't mean that a) it's actually
> standardized in a useful fashion and b) something we should just
> blindly adopt.
>
> Also like where exactly did you understand that I'm against gpus in
> HPC uses cases. Approaching this in a slightly less tribal way would
> really, really help to get something landed (which I'd like to see
> happen, personally). Always spinning this as an Intel vs AMD thing
> like you do here with every reply really doesn't help moving this in.
>
> So yeah stricter isolation is something customers want, it's just not
> something we can really give out right now at a level below the
> device.
> -Daniel
>
> >
> > Regards,
> > Kenny
> >
> > On Tue, Apr 14, 2020 at 8:52 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > > On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > My understanding from talking with a few other folks is that
> > > > > the cpumask-style CU-weight thing is not something any other gpu can
> > > > > reasonably support (and we have about 6+ of those in-tree)
> > > >
> > > > How does Intel plan to support the SubDevice API as described in your
> > > > own spec here:
> > > > https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
> > >
> > > I can't talk about whether future products might or might not support
> > > stuff and in what form exactly they might support stuff or not support
> > > stuff. Or why exactly that's even in the spec there or not.
> > >
> > > Geez
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 13:50 ` Kenny Ho
@ 2020-04-14 14:04 ` Daniel Vetter
2020-04-14 14:29 ` Kenny Ho
0 siblings, 1 reply; 30+ messages in thread
From: Daniel Vetter @ 2020-04-14 14:04 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
On Tue, Apr 14, 2020 at 3:50 PM Kenny Ho <y2kenny@gmail.com> wrote:
>
> Hi Daniel,
>
> I appreciate many of your review so far and I much prefer keeping
> things technical but that is very difficult to do when I get Intel
> developers calling my implementation "most AMD-specific solution
> possible" and objecting to an implementation because their hardware
> cannot support it. Can you help me with a more charitable
> interpretation of what has been happening?
This is upstream. It's your job to show that this can be done,
reasonable, on other devices. This doesn't need to be an intel device,
you can pretty much pick any other driver stack and show that
sufficiently many of them can support what you want to do. But as long
as all I can see is something that only works on AMD, it's not useful
as an upstreamable resource management thing.
This has _nothing_ to do with Intel (I think over the past 25 years or
so intel has implemented all 4 versions of gpu splitting that I
listed, but not entirely sure).
So again pls less tribal fighting, more collaboration. If you can't do
that, let's pick nouveau/nvidia as arbitrary neutral ground.
> Perhaps the following questions can help keep the discussion technical:
> 1) Is it possible to implement non-work-conserving distribution of
> GPU without spatial sharing? (If yes, I'd love to hear a suggestion,
> if not...question 2.)
> 2) If spatial sharing is required to support GPU HPC use cases, what
> would you implement if you have the hardware support today?
The thing we can currently do in upstream (from how I'm understanding
hw) is assign entire PCI devices to containers, so essentially only
the entire /dev/dri/* cdev. That works, and it works across all
drivers we have in upstream right now.
Anything more fine-grained I don't think is currently possible,
because everyone has a different idea of how to split up gpus. It
would be nice to have it, but in upstream, cross-vendor, I'm just not
seeing it happen right now.
-Daniel
>
> Regards,
> Kenny
>
> On Tue, Apr 14, 2020 at 9:26 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Tue, Apr 14, 2020 at 3:14 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > >
> > > Ok. I was hoping you can clarify the contradiction between the
> > > existance of the spec below and your "not something any other gpu can
> > > reasonably support" statement. I mean, OneAPI is Intel's spec and
> > > doesn't that at least make SubDevice support "reasonable" for one more
> > > vendor?
> > >
> > > Partisanship aside, as a drm co-maintainer, do you really not see the
> > > need for non-work-conserving way of distributing GPU as a resource?
> > > You recognized the latencies involved (although that's really just
> > > part of the story... time sharing is never going to be good enough
> > > even if your switching cost is zero.) As a drm co-maintainer, are you
> > > suggesting GPU has no place in the HPC use case?
> >
> > So I did chat with people and my understanding for how this subdevice
> > stuff works is roughly, from least to most fine grained support:
> > - Not possible at all, hw doesn't have any such support
> > - The hw is actually not a single gpu, but a bunch of chips behind a
> > magic bridge/interconnect, and there's a scheduler load-balancing
> > stuff and you can't actually run on all "cores" in parallel with one
> > compute/3d job. So subdevices just give you some of these cores, but
> > from client api pov they're exactly as powerful as the full device. So
> > this kinda works like assigning an entire NUMA node, including all the
> > cpu cores and memory bandwidth and everything.
> > - Hw has multiple "engines" which share resources (like compute cores
> > or whatever) behind the scenes. There's no control over how this
> > sharing works really, and whether you have guarantees about minimal
> > execution resources or not. This kinda works like hyperthreading.
> > - Then finally we have the CU mask thing amdgpu has. Which works like
> > what you're proposing, works on amd.
> >
> > So this isn't something that I think we should standardize in a
> > resource management framework like cgroups. Because it's a complete
> > mess. Note that _all_ the above things (including the "no subdevices"
> > one) are valid implementations of "subdevices" in the various specs.
> >
> > Now on your question on "why was this added to various standards?"
> > because opencl has that too (and the rocm thing, and everything else
> > it seems). What I heard is that a few people pushed really hard, and
> > no one objected hard enough (because not having subdevices is a
> > standards compliant implementation), so that's why it happened. Just
> > because it's in various standards doesn't mean that a) it's actually
> > standardized in a useful fashion and b) something we should just
> > blindly adopt.
> >
> > Also like where exactly did you understand that I'm against gpus in
> > HPC uses cases. Approaching this in a slightly less tribal way would
> > really, really help to get something landed (which I'd like to see
> > happen, personally). Always spinning this as an Intel vs AMD thing
> > like you do here with every reply really doesn't help moving this in.
> >
> > So yeah stricter isolation is something customers want, it's just not
> > something we can really give out right now at a level below the
> > device.
> > -Daniel
> >
> > >
> > > Regards,
> > > Kenny
> > >
> > > On Tue, Apr 14, 2020 at 8:52 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > > > On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > My understanding from talking with a few other folks is that
> > > > > > the cpumask-style CU-weight thing is not something any other gpu can
> > > > > > reasonably support (and we have about 6+ of those in-tree)
> > > > >
> > > > > How does Intel plan to support the SubDevice API as described in your
> > > > > own spec here:
> > > > > https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
> > > >
> > > > I can't talk about whether future products might or might not support
> > > > stuff and in what form exactly they might support stuff or not support
> > > > stuff. Or why exactly that's even in the spec there or not.
> > > >
> > > > Geez
> > > > -Daniel
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 14:04 ` Daniel Vetter
@ 2020-04-14 14:29 ` Kenny Ho
2020-04-14 15:01 ` Daniel Vetter
0 siblings, 1 reply; 30+ messages in thread
From: Kenny Ho @ 2020-04-14 14:29 UTC (permalink / raw)
To: Daniel Vetter
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
On Tue, Apr 14, 2020 at 10:04 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> This has _nothing_ to do with Intel (I think over the past 25 years or
> so intel has implemented all 4 versions of gpu splitting that I
> listed, but not entirely sure).
>
> So again pls less tribal fighting, more collaboration. If you can't do
> that, let's pick nouveau/nvidia as arbitrary neutral ground.
So are you saying Intel has implemented a form of masking before? I
don't think we need to just pick a vendor as a neutral ground. The
idea of spatial sharing vs time sharing is not vendor specific... it's
not even GPU specific. This is why I asked the two questions below.
> > Perhaps the following questions can help keep the discussion technical:
> > 1) Is it possible to implement non-work-conserving distribution of
> > GPU without spatial sharing? (If yes, I'd love to hear a suggestion,
> > if not...question 2.)
> > 2) If spatial sharing is required to support GPU HPC use cases, what
> > would you implement if you have the hardware support today?
>
> The thing we can currently do in upstream (from how I'm understanding
> hw) is assign entire PCI devices to containers, so essentially only
> the entire /dev/dri/* cdev. That works, and it works across all
> drivers we have in upstream right now.
>
> Anything more fine-grained I don't think is currently possible,
> because everyone has a different idea of how to split up gpus. It
> would be nice to have it, but in upstream, cross-vendor, I'm just not
> seeing it happen right now.
I understand the reality, but what would you implement to support the
concept (GPU in HPC, which you said you are not against) if you have
the hw support today? How would you support low-jitter/low-latency
sharing of a single GPU if you have whatever hardware support you need
today?
Regards,
Kenny
> > On Tue, Apr 14, 2020 at 9:26 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Apr 14, 2020 at 3:14 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > >
> > > > Ok. I was hoping you can clarify the contradiction between the
> > > > existance of the spec below and your "not something any other gpu can
> > > > reasonably support" statement. I mean, OneAPI is Intel's spec and
> > > > doesn't that at least make SubDevice support "reasonable" for one more
> > > > vendor?
> > > >
> > > > Partisanship aside, as a drm co-maintainer, do you really not see the
> > > > need for non-work-conserving way of distributing GPU as a resource?
> > > > You recognized the latencies involved (although that's really just
> > > > part of the story... time sharing is never going to be good enough
> > > > even if your switching cost is zero.) As a drm co-maintainer, are you
> > > > suggesting GPU has no place in the HPC use case?
> > >
> > > So I did chat with people and my understanding for how this subdevice
> > > stuff works is roughly, from least to most fine grained support:
> > > - Not possible at all, hw doesn't have any such support
> > > - The hw is actually not a single gpu, but a bunch of chips behind a
> > > magic bridge/interconnect, and there's a scheduler load-balancing
> > > stuff and you can't actually run on all "cores" in parallel with one
> > > compute/3d job. So subdevices just give you some of these cores, but
> > > from client api pov they're exactly as powerful as the full device. So
> > > this kinda works like assigning an entire NUMA node, including all the
> > > cpu cores and memory bandwidth and everything.
> > > - Hw has multiple "engines" which share resources (like compute cores
> > > or whatever) behind the scenes. There's no control over how this
> > > sharing works really, and whether you have guarantees about minimal
> > > execution resources or not. This kinda works like hyperthreading.
> > > - Then finally we have the CU mask thing amdgpu has. Which works like
> > > what you're proposing, works on amd.
> > >
> > > So this isn't something that I think we should standardize in a
> > > resource management framework like cgroups. Because it's a complete
> > > mess. Note that _all_ the above things (including the "no subdevices"
> > > one) are valid implementations of "subdevices" in the various specs.
> > >
> > > Now on your question on "why was this added to various standards?"
> > > because opencl has that too (and the rocm thing, and everything else
> > > it seems). What I heard is that a few people pushed really hard, and
> > > no one objected hard enough (because not having subdevices is a
> > > standards compliant implementation), so that's why it happened. Just
> > > because it's in various standards doesn't mean that a) it's actually
> > > standardized in a useful fashion and b) something we should just
> > > blindly adopt.
> > >
> > > Also like where exactly did you understand that I'm against gpus in
> > > HPC uses cases. Approaching this in a slightly less tribal way would
> > > really, really help to get something landed (which I'd like to see
> > > happen, personally). Always spinning this as an Intel vs AMD thing
> > > like you do here with every reply really doesn't help moving this in.
> > >
> > > So yeah stricter isolation is something customers want, it's just not
> > > something we can really give out right now at a level below the
> > > device.
> > > -Daniel
> > >
> > > >
> > > > Regards,
> > > > Kenny
> > > >
> > > > On Tue, Apr 14, 2020 at 8:52 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > > > > On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > My understanding from talking with a few other folks is that
> > > > > > > the cpumask-style CU-weight thing is not something any other gpu can
> > > > > > > reasonably support (and we have about 6+ of those in-tree)
> > > > > >
> > > > > > How does Intel plan to support the SubDevice API as described in your
> > > > > > own spec here:
> > > > > > https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
> > > > >
> > > > > I can't talk about whether future products might or might not support
> > > > > stuff and in what form exactly they might support stuff or not support
> > > > > stuff. Or why exactly that's even in the spec there or not.
> > > > >
> > > > > Geez
> > > > > -Daniel
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
2020-04-14 14:29 ` Kenny Ho
@ 2020-04-14 15:01 ` Daniel Vetter
0 siblings, 0 replies; 30+ messages in thread
From: Daniel Vetter @ 2020-04-14 15:01 UTC (permalink / raw)
To: Kenny Ho
Cc: Kenny Ho, Kuehling, Felix, jsparks, dri-devel, lkaplan,
Alex Deucher, amd-gfx list, Greathouse, Joseph, Tejun Heo,
cgroups, Christian König
On Tue, Apr 14, 2020 at 4:29 PM Kenny Ho <y2kenny@gmail.com> wrote:
>
> On Tue, Apr 14, 2020 at 10:04 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > This has _nothing_ to do with Intel (I think over the past 25 years or
> > so intel has implemented all 4 versions of gpu splitting that I
> > listed, but not entirely sure).
> >
> > So again pls less tribal fighting, more collaboration. If you can't do
> > that, let's pick nouveau/nvidia as arbitrary neutral ground.
>
> So are you saying Intel has implemented a form of masking before? I
> don't think we need to just pick a vendor as a neutral ground. The
> idea of spatial sharing vs time sharing is not vendor specific... it's
> not even GPU specific. This is why I asked the two questions below.
>
> > > Perhaps the following questions can help keep the discussion technical:
> > > 1) Is it possible to implement non-work-conserving distribution of
> > > GPU without spatial sharing? (If yes, I'd love to hear a suggestion,
> > > if not...question 2.)
> > > 2) If spatial sharing is required to support GPU HPC use cases, what
> > > would you implement if you have the hardware support today?
> >
> > The thing we can currently do in upstream (from how I'm understanding
> > hw) is assign entire PCI devices to containers, so essentially only
> > the entire /dev/dri/* cdev. That works, and it works across all
> > drivers we have in upstream right now.
> >
> > Anything more fine-grained I don't think is currently possible,
> > because everyone has a different idea of how to split up gpus. It
> > would be nice to have it, but in upstream, cross-vendor, I'm just not
> > seeing it happen right now.
>
> I understand the reality, but what would you implement to support the
> concept (GPU in HPC, which you said you are not against) if you have
> the hw support today? How would you support low-jitter/low-latency
> sharing of a single GPU if you have whatever hardware support you need
> today?
Whatever works on my gpu.
But there's a huge difference between what I can do for Intel, with my
Intel hat on, and ship that on some random intel-only repo or DKMS.
And what makes sense to push to upstream, because on upstream it needs
to be cross vendor and have reasonably clear semantics so that admins
understand it no matter whether you plug in an amd, nvidia or whatever
else gpu.
Yes this sucks, but as long as all the hw vendors insist on
differentiating here there's not much we can do. Maybe in the future
the VF stuff might help, but I'm not super hopeful that's actually
going to happen all that well. And the VF stuff at least works the
same way as what we currently can do already, with assigning an entire
/dev/dri/render* node to a container.
If you want more fine-grained then you (as a user) need to have
containers for amd, and different container isolation for nvidia, and
different container isolation for intel, and different container
isolation for $next_vendor, and so on. We can't just wish that there's
a standard way to manage this when there isn't. And merging
non-standard ways to split up gpus with cgroups, one for each gpu
vendor (generation maybe even?) just isn't going to work in upstream.
And really that's not a huge deal, because on the userspace side for
HPC it's the exact same sorry state of affairs, with cuda, rocm and
the oneapie effort from intel (not counting a bunch of things various
vendors tried to pull off on the soc side of things, there's even more
fun there). Standardizing the kernel management while you still need
to have different container images (these userspace generally have a
really hard time co-existing) isn't solving any real-world user
problems.
So yeah it sucks if you're a gpu compute user in some kind of server
setting :-/ And there's not really much I can do to fix this, except
tell vendors that everyone doing their own thing wont work (in
upstream, it'll work totally in all the vendor driver trees and
stacks, can't stop that).
-Daniel
> Regards,
> Kenny
>
>
> > > On Tue, Apr 14, 2020 at 9:26 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Tue, Apr 14, 2020 at 3:14 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > > >
> > > > > Ok. I was hoping you can clarify the contradiction between the
> > > > > existance of the spec below and your "not something any other gpu can
> > > > > reasonably support" statement. I mean, OneAPI is Intel's spec and
> > > > > doesn't that at least make SubDevice support "reasonable" for one more
> > > > > vendor?
> > > > >
> > > > > Partisanship aside, as a drm co-maintainer, do you really not see the
> > > > > need for non-work-conserving way of distributing GPU as a resource?
> > > > > You recognized the latencies involved (although that's really just
> > > > > part of the story... time sharing is never going to be good enough
> > > > > even if your switching cost is zero.) As a drm co-maintainer, are you
> > > > > suggesting GPU has no place in the HPC use case?
> > > >
> > > > So I did chat with people and my understanding for how this subdevice
> > > > stuff works is roughly, from least to most fine grained support:
> > > > - Not possible at all, hw doesn't have any such support
> > > > - The hw is actually not a single gpu, but a bunch of chips behind a
> > > > magic bridge/interconnect, and there's a scheduler load-balancing
> > > > stuff and you can't actually run on all "cores" in parallel with one
> > > > compute/3d job. So subdevices just give you some of these cores, but
> > > > from client api pov they're exactly as powerful as the full device. So
> > > > this kinda works like assigning an entire NUMA node, including all the
> > > > cpu cores and memory bandwidth and everything.
> > > > - Hw has multiple "engines" which share resources (like compute cores
> > > > or whatever) behind the scenes. There's no control over how this
> > > > sharing works really, and whether you have guarantees about minimal
> > > > execution resources or not. This kinda works like hyperthreading.
> > > > - Then finally we have the CU mask thing amdgpu has. Which works like
> > > > what you're proposing, works on amd.
> > > >
> > > > So this isn't something that I think we should standardize in a
> > > > resource management framework like cgroups. Because it's a complete
> > > > mess. Note that _all_ the above things (including the "no subdevices"
> > > > one) are valid implementations of "subdevices" in the various specs.
> > > >
> > > > Now on your question on "why was this added to various standards?"
> > > > because opencl has that too (and the rocm thing, and everything else
> > > > it seems). What I heard is that a few people pushed really hard, and
> > > > no one objected hard enough (because not having subdevices is a
> > > > standards compliant implementation), so that's why it happened. Just
> > > > because it's in various standards doesn't mean that a) it's actually
> > > > standardized in a useful fashion and b) something we should just
> > > > blindly adopt.
> > > >
> > > > Also like where exactly did you understand that I'm against gpus in
> > > > HPC uses cases. Approaching this in a slightly less tribal way would
> > > > really, really help to get something landed (which I'd like to see
> > > > happen, personally). Always spinning this as an Intel vs AMD thing
> > > > like you do here with every reply really doesn't help moving this in.
> > > >
> > > > So yeah stricter isolation is something customers want, it's just not
> > > > something we can really give out right now at a level below the
> > > > device.
> > > > -Daniel
> > > >
> > > > >
> > > > > Regards,
> > > > > Kenny
> > > > >
> > > > > On Tue, Apr 14, 2020 at 8:52 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > >
> > > > > > On Tue, Apr 14, 2020 at 2:47 PM Kenny Ho <y2kenny@gmail.com> wrote:
> > > > > > > On Tue, Apr 14, 2020 at 8:20 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > My understanding from talking with a few other folks is that
> > > > > > > > the cpumask-style CU-weight thing is not something any other gpu can
> > > > > > > > reasonably support (and we have about 6+ of those in-tree)
> > > > > > >
> > > > > > > How does Intel plan to support the SubDevice API as described in your
> > > > > > > own spec here:
> > > > > > > https://spec.oneapi.com/versions/0.7/oneL0/core/INTRO.html#subdevice-support
> > > > > >
> > > > > > I can't talk about whether future products might or might not support
> > > > > > stuff and in what form exactly they might support stuff or not support
> > > > > > stuff. Or why exactly that's even in the spec there or not.
> > > > > >
> > > > > > Geez
> > > > > > -Daniel
> > > > > > --
> > > > > > Daniel Vetter
> > > > > > Software Engineer, Intel Corporation
> > > > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 30+ messages in thread