On 3/18/2021 3:16 AM, Daniel Vetter wrote:
> On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote:
>>
>>
>> On 2/11/2021 7:34 AM, Daniel Vetter wrote:
>>> On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote:
>>>>
>>>> On 2/9/2021 2:
On 2/11/2021 7:34 AM, Daniel Vetter wrote:
> On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote:
>>
>> On 2/9/2021 2:54 AM, Daniel Vetter wrote:
>>> On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
>>>> This patch adds tracking of
On 2/9/2021 2:54 AM, Daniel Vetter wrote:
> On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
>> This patch adds tracking of which cgroup to make charges against for a
>> given GEM object. We associate the current task's cgroup with GEM objects
>> as they are
On 2/3/2021 5:25 AM, Joonas Lahtinen wrote:
> Quoting Brian Welty (2021-01-26 23:46:24)
>> Single control below is added to DRM cgroup controller in order to track
>> user execution time for GPU devices. It is up to device drivers to
>> charge execution t
On 1/28/2021 7:00 PM, Xingyou Chen wrote:
> 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 fro
regions.
FIXME: to release drm cgroup reference requires this additional patch:
https://patchwork.freedesktop.org/patch/349029
Signed-off-by: Brian Welty
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_region.c | 23 ++
drivers/gpu/drm
emory ownership", this seems
acceptable [1].
[1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory Ownership"
Signed-off-by: Brian Welty
---
drivers/gpu/drm/drm_gem.c | 89 +++
include/drm/drm_gem.h | 17
2 files changed, 106
device. The expectation is that this is incremented by DRM device
driver's scheduler upon user context completion or context switch.
Units of time are in microseconds for consistency with cpu.stats.
Signed-off-by: Brian Welty
---
Documentation/admin-guide/cgroup-v2.rst | 9
using procfs.
memory.total
Read-only value, displays total memory for a device, shown
only in root cgroup.
Signed-off-by: Brian Welty
---
Documentation/admin-guide/cgroup-v2.rst | 4
include/drm/drm_cgroup.h| 2 ++
kernel/cgroup/drm.c
is already
handled by the mm subsystem and existing memory accounting controls.
Signed-off-by: Brian Welty
---
Documentation/admin-guide/cgroup-v2.rst | 29 -
include/drm/drm_cgroup.h| 20
include/linux/cgroup_drm.h | 4 +-
kernel/cgroup/drm.c
through all existing drm cgroups and initialize them with the new device
accordingly.
Extending Kenny's original work, this has been simplified some and
the custom_init callback has been removed. (Brian)
Signed-off-by Kenny Ho
Signed-off-by: Brian Welty
---
drivers/gpu/drm/drm_drv.c | 3
-devel/2020-February/254986.html
[2] https://lists.freedesktop.org/archives/dri-devel/2020-February/254990.html
Co-developed-by: Kenny Ho
Signed-off-by: Brian Welty
---
include/drm/drm_cgroup.h | 5 ++
kernel/cgroup/drm.c | 102 +++
2 files changed, 107
From: 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
From: 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
changes to use cgroups for device memory charging
and enforcing device memory allocation limit.
[1] https://lists.freedesktop.org/archives/dri-devel/2020-February/257052.html
[2] https://lists.freedesktop.org/archives/dri-devel/2019-November/242599.html
Brian Welty (6):
drmcg: Add skeleton
ed fields are zero.
>
> This should prevent the test from auto-failing if we extend the data in
> the future.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Brian Welty
Reviewed-by: Brian Welty
> ---
> tests/i915/i915_query.c | 5 -
> 1 file changed, 5 deletions(-)
>
>
rious events (idling, reset, activity etc).
>
> When constructing the table of register definitions, also include the
> flags for which registers are valid so that information is computed
> centrally and available to all callers.
>
> Signed-off-by: Chris Wilson
> Cc: Brian We
On 2/12/2020 4:34 PM, Chris Wilson wrote:
> Quoting Brian Welty (2020-02-13 00:14:18)
>> For DGFX devices, the MOCS control value is not initialized or used.
>
> Then why is the table populated?
> -Chris
>
The format has changed (been reduced?) for DGFX.
drm_i915_
overage of mocs registers")
Signed-off-by: Brian Welty
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index de1f83100fb6.
On 1/16/2020 11:30 AM, Chris Wilson wrote:
> Quoting Brian Welty (2020-01-16 19:20:47)
>> As i915 is using drm_gem_private_object_init, it is best to
>> use the inverse function for cleanup: drm_gem_object_release.
>> This removes need for a shmem_release and phys_rele
As i915 is using drm_gem_private_object_init, it is best to
use the inverse function for cleanup: drm_gem_object_release.
This removes need for a shmem_release and phys_release.
Signed-off-by: Brian Welty
---
Chris, the cleanup sequence in drm_gem_object_release() vs the replaced
i915 code
by adding:
Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
And your fix here looks correct to me, so:
Reviewed-by: Brian Welty
>
> Signed-off-by: Bruce Chang
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 8
> 1 file changed, 4 insert
On 8/28/2019 11:50 PM, Daniel Vetter wrote:
> On Wed, Aug 28, 2019 at 08:31:27PM +, Souza, Jose wrote:
>> On Wed, 2019-08-28 at 21:13 +0100, Chris Wilson wrote:
>>> Quoting Souza, Jose (2019-08-28 21:11:53)
Reviewed-by: José Roberto de Souza
>>>
>>> It's using a non-standard for i915
On 9/26/2019 7:25 AM, Chris Wilson wrote:
> Moving our primary irq handler to a RT thread incurs an extra 1us delay
> in process interrupts. This is most notice in waking up client threads,
> where it adds about 20% of extra latency. It also imposes a delay in
> feeding the GPU, an extra 1us
shared structure
> either.
>
Thanks for the feedback. I can remove it too.
I was unsure if might be a case for having it in future.
Well, struct drm_mem_region will be quite small then if it only has a
size and type field.
Hardly seems worth introducing a new structure if these are the only
. Also if we expand I guess we need to teach
> ttm to cope with more, or maybe treat the DRM one as some kind of
> sub-flavour.
Daniel, maybe what i915 calls stolen could just be DRM_MEM_RESERVED or
DRM_MEM_PRIV. Or maybe can argue it falls into UNTRANSLATED type that
I suggested above, I'm not sure.
-B
is
in progress to add vram support to i915 [2].
[1] https://lists.freedesktop.org/archives/dri-devel/2019-June/224501.html
[2] https://lists.freedesktop.org/archives/intel-gfx/2019-June/203649.html
Brian Welty (3):
drm: introduce new struct drm_mem_region
drm: Introduce DRM_MEM defines
into drm_mem_region and drm_gem_object strucures.
vmwgfx changes included here as just example of what driver updates will
look like, and can be moved later to separate patch. Other TTM drivers
need to be updated similarly.
Signed-off-by: Brian Welty
---
drivers/gpu/drm/ttm/ttm_bo.c | 34
-gfx/2019-June/203649.html
Signed-off-by: Brian Welty
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm
Introduce DRM memory region types to be common for both drivers using
TTM and for i915. For now, TTM continues to define it's own set but
uses the DRM base definitions.
Signed-off-by: Brian Welty
---
include/drm/drm_mm.h| 8
include/drm/ttm/ttm_placement.h | 8
2
Introduce DRM memory region types to be common for both drivers using
TTM and for i915. For now, TTM continues to define it's own set but
uses the DRM base definitions.
Signed-off-by: Brian Welty
---
include/drm/drm_mm.h| 8
include/drm/ttm/ttm_placement.h | 8
2
-gfx/2019-June/203649.html
Signed-off-by: Brian Welty
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm
into drm_mem_region and drm_gem_object strucures.
vmwgfx changes included here as just example of what driver updates will
look like, and can be moved later to separate patch. Other TTM drivers
need to be updated similarly.
Signed-off-by: Brian Welty
---
drivers/gpu/drm/ttm/ttm_bo.c | 34
://lists.freedesktop.org/archives/intel-gfx/2019-June/203649.html
Brian Welty (3):
drm: introduce new struct drm_mem_region
drm: Introduce DRM_MEM defines for specifying type of drm_mem_region
drm/i915: Update intel_memory_region to use nested drm_mem_region
drivers/gpu/drm/i915/gem/i915_gem_object.c
...@lists.freedesktop.org
Cc: Matt Roper
Signed-off-by: Brian Welty
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/intel_memory_region.c | 24 ++
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu
: cgro...@vger.kernel.org
Signed-off-by: Brian Welty
---
kernel/cgroup/cgroup-v1.c | 10
kernel/cgroup/cgroup.c| 48 +--
2 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index
[1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory Ownership"
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: dri-de...@lists.freedesktop.org
Cc: Matt Roper
Signed-off-by: Brian Welty
---
drivers/gpu/drm/drm_drv.c | 12
drivers/gpu/drm/drm_gem.c | 7
charging to device
files is supported.
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: dri-de...@lists.freedesktop.org
Cc: Matt Roper
Signed-off-by: Brian Welty
---
include/linux/memcontrol.h | 10 ++
mm/memcontrol.c| 183 ++---
2 files changed
to follow?
[1] https://patchwork.freedesktop.org/series/56683/
[2] https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html
[3] https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
Brian Welty (5):
cgroup: Add cgroup_subsys per-device registration framework
cgroup_register_device. cgroup_device_unregister will
remove files from all current cgroups.
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: dri-de...@lists.freedesktop.org
Cc: Matt Roper
Signed-off-by: Brian Welty
---
include/linux/cgroup-defs.h | 28
include/linux/cgroup.h | 3 +
kernel
40 matches
Mail list logo
