[RFC PATCH 5/6] drm/amdgpu: Add cgroups implementation

Similar to xe, enable some simple management of VRAM only. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 ++ 3 files changed, 14 insertions

Re: [RFC PATCH 00/18] TTM interface for managing VRAM oversubscription

Hey, Den 2024-04-24 kl. 18:56, skrev Friedrich Vock: Hi everyone, recently I've been looking into remedies for apps (in particular, newer games) that experience significant performance loss when they start to hit VRAM limits, especially on older or lower-end cards that struggle to fit both

Re: [Intel-gfx] [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.

Hey, On 2023-05-11 12:14, Tvrtko Ursulin wrote: > > On 10/05/2023 19:46, Tejun Heo wrote: >> Hello, >> >> On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote: >>> The misc controller is not granular enough. A single computer may have any >&

Re: [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.

Hey, On 2023-05-10 20:46, Tejun Heo wrote: > Hello, > > On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote: >> The misc controller is not granular enough. A single computer may have any >> number of >> graphics cards, some of them with multiple regi

Re: [RFC PATCH 0/4] Add support for DRM cgroup memory accounting.

Hey, On 2023-05-05 21:50, Tejun Heo wrote: Hello, On Wed, May 03, 2023 at 10:34:56AM +0200, Maarten Lankhorst wrote: RFC as I'm looking for comments. For long running compute, it can be beneficial to partition the GPU memory between cgroups, so each cgroup can use its maximum amount

Re: [Intel-gfx] [RFC PATCH 2/4] drm/cgroup: Add memory accounting to DRM cgroup

I just now noticed the other comments. Wiill address them. On 2023-05-03 17:31, Tvrtko Ursulin wrote: On 03/05/2023 09:34, Maarten Lankhorst wrote: Based roughly on the rdma and misc cgroup controllers, with a lot of the accounting code borrowed from rdma. The interface is simple: - populate

Re: [Intel-gfx] [RFC PATCH 2/4] drm/cgroup: Add memory accounting to DRM cgroup

On 2023-05-03 17:31, Tvrtko Ursulin wrote: On 03/05/2023 09:34, Maarten Lankhorst wrote: Based roughly on the rdma and misc cgroup controllers, with a lot of the accounting code borrowed from rdma. The interface is simple: - populate drmcgroup_device->regions[..] name and size for e

Re: [Intel-xe] [RFC PATCH 3/4] drm/ttm: Handle -EAGAIN in ttm_resource_alloc as -ENOSPC.

On 2023-05-03 11:11, Thomas Hellström wrote: Hi, Maarten On 5/3/23 10:34, Maarten Lankhorst wrote: This allows the drm cgroup controller to return no space is available.. XXX: This is a hopeless simplification that changes behavior, and returns -ENOSPC even if we could evict ourselves from

[RFC PATCH 2/4] drm/cgroup: Add memory accounting to DRM cgroup

ent amount of allocated memory used by this cgroup. drm.events shows the amount of time max memory was reached. Signed-off-by: Maarten Lankhorst --- Documentation/admin-guide/cgroup-v2.rst | 46 ++ Documentation/gpu/drm-compute.rst | 54 +++ include/linux/cgroup_drm.h |

[RFC PATCH 4/4] drm/xe: Add support for the drm cgroup

Add some code to implement basic support for the vram0, vram1 and stolen memory regions. I fear the try_charge code should probably be done inside TTM. This code should interact with the shrinker, but for a simple RFC it's good enough. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/xe

[RFC PATCH 3/4] drm/ttm: Handle -EAGAIN in ttm_resource_alloc as -ENOSPC.

the current cgroup or its parents. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_bo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index bd5dae4d1624..e057d5d8f09a 100644 --- a/drivers/gpu/drm/ttm

[RFC PATCH 1/4] cgroup: Add the DRM cgroup controller

From: Tvrtko Ursulin Skeleton controller without any functionality. Signed-off-by: Tvrtko Ursulin Signed-off-by: Maarten Lankhorst --- include/linux/cgroup_drm.h| 9 ++ include/linux/cgroup_subsys.h | 4 +++ init/Kconfig | 7 kernel/cgroup/Makefile

[RFC PATCH 0/4] Add support for DRM cgroup memory accounting.

accounting, so I only ended up keeping the base patch. Xe is not upstream yet, so the driver specific patch will only apply on https://gitlab.freedesktop.org/drm/xe/kernel Maarten Lankhorst (3): drm/cgroup: Add memory accounting to DRM cgroup drm/ttm: Handle -EAGAIN in ttm_resource_alloc as -ENOSPC

Re: [PATCH 1/6] dma-buf: move dma_resv_prune_unlocked into dma_resv.c

On 28-10-2021 15:26, Christian König wrote: > The i915 driver implements a prune function which is called when it is very > likely that the fences inside the dma_resv object can be removed because they > are all signaled. > > Move that function into the dma-resv.c code since the behavior of

Re: [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

running compute > workloads or workloads where userspace fencing is allowed. > > v2: Now with dot graph! > > v3: Typo (Dave Airlie) For first 5 patches, and patch 16, 17: Reviewed-by: Maarten Lankhorst > Acked-by: Christian König > Acked-by: Daniel Stone > Cc: Jesse Nata

Re: [PATCH] dma-fence: basic lockdep annotations

ndle soft/hardirq ctx better against write side and dont forget > EXPORT_SYMBOL, drivers can't use this otherwise. > > v3: Kerneldoc. > > v4: Some spelling fixes from Mika > > v5: Amend commit message to explain in detail why cross-release isn't > the solution. > >

Re: [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

er.kernel.org >> Cc: amd-gfx@lists.freedesktop.org >> Cc: intel-...@lists.freedesktop.org >> Cc: Chris Wilson >> Cc: Maarten Lankhorst >> Cc: Christian König >> Signed-off-by: Daniel Vetter >> --- >>   drivers/dma-buf/dma-fence.c | 3 +++ >>  

Re: [RFC 02/17] dma-fence: basic lockdep annotations

annotations > cannot be sprinkled over the code entirely mindless to avoid false > positives. > > v2: handle soft/hardirq ctx better against write side and dont forget > EXPORT_SYMBOL, drivers can't use this otherwise. > > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@li

Re: [PATCH] drm/amdgpu: Fix connector atomic_check compilation fail

to > accept drm_atomic_state") > Cc: Daniel Vetter > Cc: Ville Syrjälä > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Ben Skeggs > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Eric Anholt > Cc: Laurent Pinchart [for rcar lvds]

Re: [PATCH] drm/gamma: Clarify gamma lut uapi

of 0x. > > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc: Shashank Sharma > Cc: "Kumar, Kiran S" > Cc: Kausal Malladi > Cc: Lionel Landwerlin > Cc: Matt Roper > Cc: Rob Bradford > Cc: Daniel Stone > Cc: Stefan Schake > Cc: Eric Anholt > Cc: M

Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

Op 12-11-18 om 17:11 schreef Sean Paul: > On Mon, Nov 12, 2018 at 04:01:14PM +0100, Maarten Lankhorst wrote: >> We already have __drm_atomic_helper_connector_reset() and >> __drm_atomic_helper_plane_reset(), extend this to crtc as well. >> >> Most drivers already hav

[PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

-by: Maarten Lankhorst Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: David Airlie Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers Cc: Boris Brezillon Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic De

Re: [PATCH] drm: Print unadorned pointers

ni Nikula <jani.nik...@linux.intel.com> > Cc: "Jerry (Fangzhi) Zuo" <jerry@amd.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Krzysztof Kozlowski <k...@kernel.org> > Cc: "Leo (Sunpeng) Li" <sunpeng...@amd.com> >

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

Op 21-02-18 om 00:56 schreef Daniel Vetter: > On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote: >> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote: >>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:

Re: [PATCH 0/6] Use new DRM API where possible, and cleanups.

2 files changed, 156 insertions(+), 167 deletions(-) > Better, only scanned through the series but Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] amdgpu/dc: Use DRM new-style object iterators.

Op 11-10-17 om 22:40 schreef Harry Wentland: > On 2017-10-11 03:46 PM, Maarten Lankhorst wrote: >> Op 11-10-17 om 20:55 schreef Leo: >>> >>> On 2017-10-11 10:30 AM, Maarten Lankhorst wrote: >>>> Op 11-10-17 om 16:24 schreef sunpeng...@amd.com: >>>

Re: [PATCH] amdgpu/dc: Use DRM new-style object iterators.

Op 11-10-17 om 20:55 schreef Leo: > > > On 2017-10-11 10:30 AM, Maarten Lankhorst wrote: >> Op 11-10-17 om 16:24 schreef sunpeng...@amd.com: >>> From: "Leo (Sunpeng) Li" <sunpeng...@amd.com> >>> >>> Use the correct for_each_new/old_

Re: [PATCH] amdgpu/dc: Use DRM new-style object iterators.

Op 11-10-17 om 16:24 schreef sunpeng...@amd.com: > From: "Leo (Sunpeng) Li" > > Use the correct for_each_new/old_* iterators instead of for_each_* > > List of affected functions: > > amdgpu_dm_find_first_crtc_matching_connector: use for_each_new > - Old from_state_var flag

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

Op 11-09-17 om 17:24 schreef Christian König: > Am 11.09.2017 um 17:22 schrieb Christian König: >> Am 11.09.2017 um 17:13 schrieb Maarten Lankhorst: >>> Op 11-09-17 om 16:45 schreef Christian König: >>>> Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst: >>>&g

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

Op 11-09-17 om 16:45 schreef Christian König: > Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst: >> Op 11-09-17 om 14:53 schreef Christian König: >>> Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst: >>>> Op 04-09-17 om 21:02 schreef Christian König: >>>

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

Op 11-09-17 om 14:53 schreef Christian König: > Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst: >> Op 04-09-17 om 21:02 schreef Christian König: >>> From: Christian König <christian.koe...@amd.com> >>> >>> Stop requiring that the src reser

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

Op 04-09-17 om 21:02 schreef Christian König: > From: Christian König > > Stop requiring that the src reservation object is locked for this operation. > > Signed-off-by: Christian König > --- > drivers/dma-buf/reservation.c | 56 >

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Op 27-06-17 om 17:01 schreef Daniel Vetter: > On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote: >> Op 27-06-17 om 09:37 schreef Daniel Vetter: >>> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: >>>> On 2017-06-20 01:57 PM, Andrey G

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Op 27-06-17 om 09:37 schreef Daniel Vetter: > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote: >>> Problem : While running IGT kms_atomic_transition test suite i encountered >>> a hang in drmHandleEvent immediately following an

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Op 09-06-17 om 23:30 schreef Andrey Grodzovsky: > Problem: > While running IGT kms_atomic_transition test suite i encountered > a hang in drmHandleEvent immidietly follwoing an atomic_commit. > After dumping the atomic state I relized that in this case there was > not even one CRTC attached to the