Linaro-mm-sig February 2026

linaro-mm-sig@lists.linaro.org

129 participants
1793 discussions

[PATCH v4 00/12] drm/amdgpu: use all SDMA instances for TTM clears and moves

by Pierre-Eric Pelloux-Prayer

The drm/ttm patch modifies TTM to support multiple contexts for the pipelined moves. Then amdgpu/ttm is updated to express dependencies between jobs explicitely, instead of relying on the ordering of execution guaranteed by the use of a single instance. With all of this in place, we can use multiple entities, with each having access to the available SDMA instances. This rework also gives the opportunity to merge the clear functions into a single one and to optimize a bit GART usage. Since v3 some patches have been already reviewed and merged separately: - https://lists.freedesktop.org/archives/amd-gfx/2026-January/137747.html - https://gitlab.freedesktop.org/drm/kernel/-/commit/ddf055b80a544d6f36f77be5… This version depend on them. v3: https://lists.freedesktop.org/archives/dri-devel/2025-November/537830.html Pierre-Eric Pelloux-Prayer (12): drm/amdgpu: allocate clear entities dynamically drm/amdgpu: allocate move entities dynamically drm/amdgpu: round robin through clear_entities in amdgpu_fill_buffer drm/amdgpu: use TTM_NUM_MOVE_FENCES when reserving fences drm/amdgpu: use multiple entities in amdgpu_move_blit drm/amdgpu: pass all the sdma scheds to amdgpu_mman drm/amdgpu: only use working sdma schedulers for ttm drm/amdgpu: create multiple clear/move ttm entities drm/amdgpu: give ttm entities access to all the sdma scheds drm/amdgpu: get rid of amdgpu_ttm_clear_buffer drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_ttm_clear_buffer drm/amdgpu: split amdgpu_ttm_set_buffer_funcs_status in 2 funcs drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 329 ++++++++++-------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 29 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 6 +- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 13 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 8 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 8 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 15 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 12 +- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 11 +- drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 14 +- drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/sdma_v7_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/sdma_v7_1.c | 12 +- drivers/gpu/drm/amd/amdgpu/si_dma.c | 12 +- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 5 +- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 +- .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 6 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c | 6 +- 23 files changed, 300 insertions(+), 243 deletions(-) -- 2.43.0

4 months, 3 weeks

[PATCH] dma-buf: heaps: cma: register a dmem region for each cma heap

by Eric Chanudet

The cma dma-buf heaps let userspace allocate buffers in CMA regions without enforcing limits. Register a dmem region per cma heap and charge against it when allocating a buffer in a cma heap. For the default cma region, two heaps may be created for the same cma range: commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name") Introduced /dev/dma_heap/default_cma_region commit 4f5f8baf7341 ("dma-buf: heaps: cma: Create CMA heap for each CMA reserved region") Created a CMA heap for each CMA region, which might create a duplicate heap to the default one, e.g: /dev/dma_heap/default_cma_region /dev/dma_heap/reserved Removing the legacy heap would break user API. So handle the special case by using one dmem between the two heaps to account charges correctly. Signed-off-by: Eric Chanudet <echanude(a)redhat.com> --- In continuation with introducing cgroup for the system heap[1], this behavior is enabled based on dma_heap.mem_accounting, disabled by default. dmem is chosen for CMA heaps as it allows limits to be set for each region backing each heap. There is one caveat for the default cma range that may accessible through two different cma heaps, which is treated as a special case. [1] https://lore.kernel.org/all/20260116-dmabuf-heap-system-memcg-v3-0-ecc6b62c… --- drivers/dma-buf/heaps/cma_heap.c | 51 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 5 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 49cc45fb42dd7200c3c14384bcfdbe85323454b1..608af8ad6bce7fe0321da6d8f1b65a69f5d8d950 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -27,6 +27,7 @@ #include <linux/scatterlist.h> #include <linux/slab.h> #include <linux/vmalloc.h> +#include <linux/cgroup_dmem.h> #define DEFAULT_CMA_NAME "default_cma_region" @@ -46,7 +47,9 @@ int __init dma_heap_cma_register_heap(struct cma *cma) struct cma_heap { struct dma_heap *heap; struct cma *cma; + struct dmem_cgroup_region *cg; }; +static struct dmem_cgroup_region *default_cma_cg; struct cma_heap_buffer { struct cma_heap *heap; @@ -58,6 +61,7 @@ struct cma_heap_buffer { pgoff_t pagecount; int vmap_cnt; void *vaddr; + struct dmem_cgroup_pool_state *pool; }; struct dma_heap_attachment { @@ -276,6 +280,7 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf) kfree(buffer->pages); /* release memory */ cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount); + dmem_cgroup_uncharge(buffer->pool, buffer->len); kfree(buffer); } @@ -319,9 +324,16 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, if (align > CONFIG_CMA_ALIGNMENT) align = CONFIG_CMA_ALIGNMENT; + if (mem_accounting) { + ret = dmem_cgroup_try_charge(cma_heap->cg, size, + &buffer->pool, NULL); + if (ret) + goto free_buffer; + } + cma_pages = cma_alloc(cma_heap->cma, pagecount, align, false); if (!cma_pages) - goto free_buffer; + goto uncharge_cgroup; /* Clear the cma pages */ if (PageHighMem(cma_pages)) { @@ -376,6 +388,8 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, kfree(buffer->pages); free_cma: cma_release(cma_heap->cma, cma_pages, pagecount); +uncharge_cgroup: + dmem_cgroup_uncharge(buffer->pool, size); free_buffer: kfree(buffer); @@ -390,25 +404,52 @@ static int __init __add_cma_heap(struct cma *cma, const char *name) { struct dma_heap_export_info exp_info; struct cma_heap *cma_heap; + struct dmem_cgroup_region *region; + int ret; cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL); if (!cma_heap) return -ENOMEM; cma_heap->cma = cma; + /* + * If two heaps are created for the default cma region, use the same + * dmem for them. They both use the same memory pool. + */ + if (dev_get_cma_area(NULL) == cma && default_cma_cg) + region = default_cma_cg; + else { + region = dmem_cgroup_register_region(cma_get_size(cma), "cma/%s", name); + if (IS_ERR(region)) { + ret = PTR_ERR(region); + goto free_cma_heap; + } + } + cma_heap->cg = region; + exp_info.name = name; exp_info.ops = &cma_heap_ops; exp_info.priv = cma_heap; cma_heap->heap = dma_heap_add(&exp_info); if (IS_ERR(cma_heap->heap)) { - int ret = PTR_ERR(cma_heap->heap); - - kfree(cma_heap); - return ret; + ret = PTR_ERR(cma_heap->heap); + goto cg_unregister; } + if (dev_get_cma_area(NULL) == cma && !default_cma_cg) + default_cma_cg = region; + return 0; + +cg_unregister: + /* default_cma_cg == cma_heap->cg only for the duplicate heap. */ + if (default_cma_cg != cma_heap->cg) + dmem_cgroup_unregister_region(cma_heap->cg); +free_cma_heap: + kfree(cma_heap); + + return ret; } static int __init add_cma_heaps(void) --- base-commit: 3d65e4c276b32c03450261d114e495fda03c8e97 change-id: 20260128-dmabuf-heap-cma-dmem-f4120a2df4a8 Best regards, -- Eric Chanudet <echanude(a)redhat.com>

4 months, 3 weeks

Hire SAFEGUARD RECOVERY, a Bitcoin recovery specialist, to retrieve stolen or lost coins.

by sophia fourest

I invested $320,000 in Tether (USDT) on a fraudulent website after falling for a romantic scam. I felt completely helpless and in need of assistance after realizing I had been duped. I started looking for a hacker online and found SAFEGUARD RECOVERY. I had optimism because of his professionalism and knowledge. I'm happy to report that SAFEGUARD RECOVERY successfully recovered my stolen money after working relentlessly to do so! I am immensely appreciative of their help and heartily urge anyone in a comparable circumstance to use their services. I'm grateful Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

4 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig February 2026