drivers 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
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
on logic.
[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_g
ll, such that hierarchial 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 +
: 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
ri-de...@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/driver
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 befor
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 er
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
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 is
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_release
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 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_obj
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 --
-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
ields 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
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 --
-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
which 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 define
ields 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
oing to be stolen for
> discrete vram for us ... 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
ot sure we want any of these details in this 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 intro
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 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_moc
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
implements i915 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):
drmc
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
per-
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
-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
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
ry 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/
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
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
sion of "memory 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 fil
emory 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/gp
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 serie
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 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 a
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 which
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:54
re 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(-)
>
>
40 matches
Mail list logo
