All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xingyou Chen <rockrush@rockwork.org>
To: "Brian Welty" <brian.welty@intel.com>,
	cgroups@vger.kernel.org, "Tejun Heo" <tj@kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Christian König" <christian.koenig@amd.com>,
	"Kenny Ho" <Kenny.Ho@amd.com>,
	amd-gfx@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Eero Tamminen" <eero.t.tamminen@intel.com>
Subject: Re: [RFC PATCH 0/9] cgroup support for GPU devices
Date: Fri, 29 Jan 2021 11:00:56 +0800	[thread overview]
Message-ID: <84b79978-84c9-52aa-b761-3f4be929064e@rockwork.org> (raw)
In-Reply-To: <20210126214626.16260-1-brian.welty@intel.com>

On 2021/1/27 上午5:46, Brian Welty wrote:

> We'd like to revisit the proposal of a GPU cgroup controller for managing
> GPU devices but with just a basic set of controls.  This series is based on 
> the prior patch series from Kenny Ho [1].  We take Kenny's base patches
> which implement the basic framework for the controller, but we propose an
> alternate set of control files.  Here we've taken a subset of the controls
> proposed in earlier discussion on ML here [2]. 
>
> This series proposes a set of device memory controls (gpu.memory.current,
> gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage
> (gpu.sched.runtime).  GPU time sharing controls are left as future work.
> These are implemented within the GPU controller along with integration/usage
> of the device memory controls by the i915 device driver.
>
> As an accelerator or GPU device is similar in many respects to a CPU with
> (or without) attached system memory, the basic principle here is try to
> copy the semantics of existing controls from other controllers when possible
> and where these controls serve the same underlying purpose.
> For example, the memory.max and memory.current controls are based on
> same controls from MEMCG controller.

It seems not to be DRM specific, or even GPU specific. Would we have an universal
control group for any accelerator, GPGPU device etc, that hold sharable resources
like device memory, compute utility, bandwidth, with extra control file to select
between devices(or vendors)?

e.g. /cgname.device that stores PCI BDF, or enum(intel, amdgpu, nvidia, ...),
defaults to none, means not enabled.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Xingyou Chen <rockrush@rockwork.org>
To: "Brian Welty" <brian.welty@intel.com>,
	cgroups@vger.kernel.org, "Tejun Heo" <tj@kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Christian König" <christian.koenig@amd.com>,
	"Kenny Ho" <Kenny.Ho@amd.com>,
	amd-gfx@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Eero Tamminen" <eero.t.tamminen@intel.com>
Subject: Re: [Intel-gfx] [RFC PATCH 0/9] cgroup support for GPU devices
Date: Fri, 29 Jan 2021 11:00:56 +0800	[thread overview]
Message-ID: <84b79978-84c9-52aa-b761-3f4be929064e@rockwork.org> (raw)
In-Reply-To: <20210126214626.16260-1-brian.welty@intel.com>

On 2021/1/27 上午5:46, Brian Welty wrote:

> We'd like to revisit the proposal of a GPU cgroup controller for managing
> GPU devices but with just a basic set of controls.  This series is based on 
> the prior patch series from Kenny Ho [1].  We take Kenny's base patches
> which implement the basic framework for the controller, but we propose an
> alternate set of control files.  Here we've taken a subset of the controls
> proposed in earlier discussion on ML here [2]. 
>
> This series proposes a set of device memory controls (gpu.memory.current,
> gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage
> (gpu.sched.runtime).  GPU time sharing controls are left as future work.
> These are implemented within the GPU controller along with integration/usage
> of the device memory controls by the i915 device driver.
>
> As an accelerator or GPU device is similar in many respects to a CPU with
> (or without) attached system memory, the basic principle here is try to
> copy the semantics of existing controls from other controllers when possible
> and where these controls serve the same underlying purpose.
> For example, the memory.max and memory.current controls are based on
> same controls from MEMCG controller.

It seems not to be DRM specific, or even GPU specific. Would we have an universal
control group for any accelerator, GPGPU device etc, that hold sharable resources
like device memory, compute utility, bandwidth, with extra control file to select
between devices(or vendors)?

e.g. /cgname.device that stores PCI BDF, or enum(intel, amdgpu, nvidia, ...),
defaults to none, means not enabled.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Xingyou Chen <rockrush@rockwork.org>
To: "Brian Welty" <brian.welty@intel.com>,
	cgroups@vger.kernel.org, "Tejun Heo" <tj@kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Christian König" <christian.koenig@amd.com>,
	"Kenny Ho" <Kenny.Ho@amd.com>,
	amd-gfx@lists.freedesktop.org,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Eero Tamminen" <eero.t.tamminen@intel.com>
Subject: Re: [RFC PATCH 0/9] cgroup support for GPU devices
Date: Fri, 29 Jan 2021 11:00:56 +0800	[thread overview]
Message-ID: <84b79978-84c9-52aa-b761-3f4be929064e@rockwork.org> (raw)
In-Reply-To: <20210126214626.16260-1-brian.welty@intel.com>

On 2021/1/27 上午5:46, Brian Welty wrote:

> We'd like to revisit the proposal of a GPU cgroup controller for managing
> GPU devices but with just a basic set of controls.  This series is based on 
> the prior patch series from Kenny Ho [1].  We take Kenny's base patches
> which implement the basic framework for the controller, but we propose an
> alternate set of control files.  Here we've taken a subset of the controls
> proposed in earlier discussion on ML here [2]. 
>
> This series proposes a set of device memory controls (gpu.memory.current,
> gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage
> (gpu.sched.runtime).  GPU time sharing controls are left as future work.
> These are implemented within the GPU controller along with integration/usage
> of the device memory controls by the i915 device driver.
>
> As an accelerator or GPU device is similar in many respects to a CPU with
> (or without) attached system memory, the basic principle here is try to
> copy the semantics of existing controls from other controllers when possible
> and where these controls serve the same underlying purpose.
> For example, the memory.max and memory.current controls are based on
> same controls from MEMCG controller.

It seems not to be DRM specific, or even GPU specific. Would we have an universal
control group for any accelerator, GPGPU device etc, that hold sharable resources
like device memory, compute utility, bandwidth, with extra control file to select
between devices(or vendors)?

e.g. /cgname.device that stores PCI BDF, or enum(intel, amdgpu, nvidia, ...),
defaults to none, means not enabled.

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Xingyou Chen <rockrush-hTEXxzOs8fRg9hUCZPvPmw@public.gmane.org>
To: "Brian Welty"
	<brian.welty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Tejun Heo" <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Daniel Vetter" <daniel-/w4YWyX8dFk@public.gmane.org>,
	"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
	"Kenny Ho" <Kenny.Ho-5C7GfCeVMHo@public.gmane.org>,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Chris Wilson"
	<chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>,
	"Tvrtko Ursulin"
	<tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Joonas Lahtinen"
	<joonas.lahtinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	"Eero Tamminen"
	<eero.t.tamminen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC PATCH 0/9] cgroup support for GPU devices
Date: Fri, 29 Jan 2021 11:00:56 +0800	[thread overview]
Message-ID: <84b79978-84c9-52aa-b761-3f4be929064e@rockwork.org> (raw)
In-Reply-To: <20210126214626.16260-1-brian.welty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

On 2021/1/27 上午5:46, Brian Welty wrote:

> We'd like to revisit the proposal of a GPU cgroup controller for managing
> GPU devices but with just a basic set of controls.  This series is based on 
> the prior patch series from Kenny Ho [1].  We take Kenny's base patches
> which implement the basic framework for the controller, but we propose an
> alternate set of control files.  Here we've taken a subset of the controls
> proposed in earlier discussion on ML here [2]. 
>
> This series proposes a set of device memory controls (gpu.memory.current,
> gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage
> (gpu.sched.runtime).  GPU time sharing controls are left as future work.
> These are implemented within the GPU controller along with integration/usage
> of the device memory controls by the i915 device driver.
>
> As an accelerator or GPU device is similar in many respects to a CPU with
> (or without) attached system memory, the basic principle here is try to
> copy the semantics of existing controls from other controllers when possible
> and where these controls serve the same underlying purpose.
> For example, the memory.max and memory.current controls are based on
> same controls from MEMCG controller.

It seems not to be DRM specific, or even GPU specific. Would we have an universal
control group for any accelerator, GPGPU device etc, that hold sharable resources
like device memory, compute utility, bandwidth, with extra control file to select
between devices(or vendors)?

e.g. /cgname.device that stores PCI BDF, or enum(intel, amdgpu, nvidia, ...),
defaults to none, means not enabled.

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2021-01-29  3:01 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 21:46 [RFC PATCH 0/9] cgroup support for GPU devices Brian Welty
2021-01-26 21:46 ` Brian Welty
2021-01-26 21:46 ` Brian Welty
2021-01-26 21:46 ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 1/9] cgroup: Introduce cgroup for drm subsystem Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 2/9] drm, cgroup: Bind drm and cgroup subsystem Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 3/9] drm, cgroup: Initialize drmcg properties Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 4/9] drmcg: Add skeleton seq_show and write for drmcg files Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 5/9] drmcg: Add support for device memory accounting via page counter Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-27  9:14   ` kernel test robot
2021-01-26 21:46 ` [RFC PATCH 6/9] drmcg: Add memory.total file Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 7/9] drmcg: Add initial support for tracking gpu time usage Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-02-03 13:25   ` Joonas Lahtinen
2021-02-03 13:25     ` Joonas Lahtinen
2021-02-03 13:25     ` [Intel-gfx] " Joonas Lahtinen
2021-02-04  2:23     ` Brian Welty
2021-02-04  2:23       ` Brian Welty
2021-02-04  2:23       ` Brian Welty
2021-02-04  2:23       ` [Intel-gfx] " Brian Welty
2021-01-26 21:46 ` [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-02-09 10:54   ` Daniel Vetter
2021-02-09 10:54     ` Daniel Vetter
2021-02-09 10:54     ` Daniel Vetter
2021-02-09 10:54     ` [Intel-gfx] " Daniel Vetter
2021-02-10  7:52     ` Thomas Zimmermann
2021-02-10  7:52       ` Thomas Zimmermann
2021-02-10  7:52       ` Thomas Zimmermann
2021-02-10  7:52       ` [Intel-gfx] " Thomas Zimmermann
2021-02-10 12:45       ` Daniel Vetter
2021-02-10 12:45         ` Daniel Vetter
2021-02-10 12:45         ` Daniel Vetter
2021-02-10 12:45         ` [Intel-gfx] " Daniel Vetter
2021-02-10 22:00     ` Brian Welty
2021-02-10 22:00       ` Brian Welty
2021-02-10 22:00       ` Brian Welty
2021-02-10 22:00       ` [Intel-gfx] " Brian Welty
2021-02-11 15:34       ` Daniel Vetter
2021-02-11 15:34         ` Daniel Vetter
2021-02-11 15:34         ` Daniel Vetter
2021-02-11 15:34         ` [Intel-gfx] " Daniel Vetter
2021-03-06  0:44         ` Brian Welty
2021-03-06  0:44           ` Brian Welty
2021-03-06  0:44           ` Brian Welty
2021-03-06  0:44           ` [Intel-gfx] " Brian Welty
2021-03-18 10:16           ` Daniel Vetter
2021-03-18 10:16             ` Daniel Vetter
2021-03-18 10:16             ` Daniel Vetter
2021-03-18 10:16             ` [Intel-gfx] " Daniel Vetter
2021-03-18 19:20             ` Brian Welty
2021-03-18 19:20               ` Brian Welty
2021-03-18 19:20               ` Brian Welty
2021-03-18 19:20               ` [Intel-gfx] " Brian Welty
2021-05-10 15:36               ` Daniel Vetter
2021-05-10 15:36                 ` Daniel Vetter
2021-05-10 15:36                 ` Daniel Vetter
2021-05-10 15:36                 ` [Intel-gfx] " Daniel Vetter
2021-05-10 16:06                 ` Tamminen, Eero T
2021-05-10 16:06                   ` Tamminen, Eero T
2021-05-10 16:06                   ` Tamminen, Eero T
2021-05-10 16:06                   ` [Intel-gfx] " Tamminen, Eero T
2021-01-26 21:46 ` [RFC PATCH 9/9] drm/i915: Use memory cgroup for enforcing device memory limit Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` Brian Welty
2021-01-26 21:46   ` [Intel-gfx] " Brian Welty
2021-01-27  6:04   ` kernel test robot
2021-01-26 22:37 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for cgroup support for GPU devices (rev3) Patchwork
2021-01-26 22:40 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-01-26 23:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-01-26 23:07 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " Patchwork
2021-01-27  4:55 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
2021-01-29  2:45 ` [RFC PATCH 0/9] cgroup support for GPU devices Xingyou Chen
2021-01-29  2:45   ` Xingyou Chen
2021-01-29  2:45   ` Xingyou Chen
2021-01-29  2:45   ` [Intel-gfx] " Xingyou Chen
2021-01-29  3:00 ` Xingyou Chen [this message]
2021-01-29  3:00   ` Xingyou Chen
2021-01-29  3:00   ` Xingyou Chen
2021-01-29  3:00   ` [Intel-gfx] " Xingyou Chen
2021-02-01 23:21   ` Brian Welty
2021-02-01 23:21     ` Brian Welty
2021-02-01 23:21     ` Brian Welty
2021-02-01 23:21     ` [Intel-gfx] " Brian Welty
2021-02-03 10:18     ` Daniel Vetter
2021-02-03 10:18       ` Daniel Vetter
2021-02-03 10:18       ` Daniel Vetter
2021-02-03 10:18       ` [Intel-gfx] " Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84b79978-84c9-52aa-b761-3f4be929064e@rockwork.org \
    --to=rockrush@rockwork.org \
    --cc=Kenny.Ho@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=brian.welty@intel.com \
    --cc=cgroups@vger.kernel.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eero.t.tamminen@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=tj@kernel.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.