Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

8 participants
2915 discussions

[PATCH 1/2] gpu: ion: Fix kmalloc leak in carveout heap

by Nishanth Peethambaran

>From 78c843052f9438a848dd91334c6392b3b861bfa1 Mon Sep 17 00:00:00 2001 From: Nishanth Peethambaran <nishanth(a)broadcom.com> Date: Wed, 5 Sep 2012 02:21:54 +0530 Subject: [PATCH 1/2] gpu: ion: Fix kmalloc leak in carveout heap In carveout_unmap_dma(), the sg_table is freed. Change-Id: I8c2372c01a3f4c9061a1756ac9b31e09cf3ab9ef Signed-off-by: Nishanth Peethambaran <nishanth(a)broadcom.com> --- drivers/gpu/ion/ion_carveout_heap.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/ion/ion_carveout_heap.c b/drivers/gpu/ion/ion_carveout_heap.c index 5b6255b..f7608bc 100644 --- a/drivers/gpu/ion/ion_carveout_heap.c +++ b/drivers/gpu/ion/ion_carveout_heap.c @@ -107,6 +107,7 @@ void ion_carveout_heap_unmap_dma(struct ion_heap *heap, struct ion_buffer *buffer) { sg_free_table(buffer->sg_table); + kfree(buffer->sg_table); } void *ion_carveout_heap_map_kernel(struct ion_heap *heap, -- 1.7.0.4

12 years, 10 months

[PATCH 2/2] gpu: ion: Fix a memory leak

by Nishanth Peethambaran

>From 03184abb0efd05a422c4525f2f4398f127a9a0c9 Mon Sep 17 00:00:00 2001 From: Nishanth Peethambaran <nishanth(a)broadcom.com> Date: Wed, 5 Sep 2012 02:49:30 +0530 Subject: [PATCH 2/2] gpu: ion: Fix a memory leak The dirty bitmap buffer for cached buffers is freed when buffer gets destroyed. Change-Id: If2b6a6e3ffc5ed57623cfcbc01cb6b720bee532f Signed-off-by: Nishanth Peethambaran <nishanth(a)broadcom.com> --- drivers/gpu/ion/ion.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c index 207d00f..3ad766a 100644 --- a/drivers/gpu/ion/ion.c +++ b/drivers/gpu/ion/ion.c @@ -176,12 +176,14 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap, return ERR_PTR(-EINVAL); } - ret = ion_buffer_alloc_dirty(buffer); - if (ret) { - heap->ops->unmap_dma(heap, buffer); - heap->ops->free(buffer); - kfree(buffer); - return ERR_PTR(ret); + if (buffer->flags & ION_FLAG_CACHED) { + ret = ion_buffer_alloc_dirty(buffer); + if (ret) { + heap->ops->unmap_dma(heap, buffer); + heap->ops->free(buffer); + kfree(buffer); + return ERR_PTR(ret); + } } buffer->dev = dev; @@ -210,6 +212,8 @@ static void ion_buffer_destroy(struct kref *kref) if (WARN_ON(buffer->kmap_cnt > 0)) buffer->heap->ops->unmap_kernel(buffer->heap, buffer); + if (buffer->flags & ION_FLAG_CACHED) + kfree(buffer->dirty); buffer->heap->ops->unmap_dma(buffer->heap, buffer); buffer->heap->ops->free(buffer); mutex_lock(&dev->lock); -- 1.7.0.4

12 years, 10 months

A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing

by Aaron Plattner

So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider object interface, so that Optimus-based laptops can use our driver to drive the discrete GPU and display on the integrated GPU. The good news is that I've got a proof of concept working. During a review of the current code, we came up with a few concerns: 1. The output source is responsible for allocating the shared memory Right now, the X server calls CreatePixmap on the output source screen and then expects the output sink screen to be able to display from whatever memory the source allocates. Right now, the source has no mechanism for asking the sink what its requirements are for the surface. I'm using our own internal pitch alignment requirements and that seems to be good enough for the Intel device to scan out, but that could be pure luck. Does it make sense to add a mechanism for drivers to negotiate this with each other, or is it sufficient to just define a lowest common denominator format and if your hardware can't deal with that format, you just don't get to share buffers? One of my coworkers brought to my attention the fact that Tegra requires a specific pitch alignment, and cannot accommodate larger pitches. If other SoC designs have similar restrictions, we might need to add a handshake mechanism. 2. There's no fallback mechanism if sharing can't be negotiated If RandR fails to share a pixmap with the output sink screen, the whole modeset fails. This means you'll end up not seeing anything on the screen and you'll probably think your computer locked up. Should there be some sort of software copy fallback to ensure that something at least shows up on the display? 3. How should the memory be allocated? In the prototype I threw together, I'm allocating the shared memory using shm_open and then exporting that as a dma-buf file descriptor using an ioctl I added to the kernel, and then importing that memory back into our driver through dma_buf_attach & dma_buf_map_attachment. Does it make sense for user-space programs to be able to export shmfs files like that? Should that interface go in DRM / GEM / PRIME instead? Something else? I'm pretty unfamiliar with this kernel code so any suggestions would be appreciated. -- Aaron P.S. for those unfamiliar with PRIME: Dave Airlie added new support to the X Resize and Rotate extension version 1.4 to support offloading display and rendering to different drivers. PRIME is the DRM implementation in the kernel, layered on top of DMA-BUF, that implements the actual sharing of buffers between drivers. http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=ra… http://airlied.livejournal.com/75555.html - update on hotplug server http://airlied.livejournal.com/76078.html - randr 1.5 demo videos ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

12 years, 10 months

[PATCH 0/3] gpu: ion: oom killer

by Zhangfei Gao

Base on common.git, android-3.4 branch Patch 2: Add support page wised cache flush for carveout_heap There is only one nents for carveout heap, as well as dirty bit. As a result, cache flush only takes effect for total carve heap. Patch 3: Add oom killer. Once heap is used off, SIGKILL is send to all tasks refered the buffer with descending oom_socre_adj Zhangfei Gao (3): gpu: ion: update carveout_heap_ops gpu: ion: carveout_heap page wised cache flush gpu: ion: oom killer drivers/gpu/ion/ion.c | 112 ++++++++++++++++++++++++++++++++++- drivers/gpu/ion/ion_carveout_heap.c | 23 ++++++-- 2 files changed, 127 insertions(+), 8 deletions(-)

12 years, 10 months

[PATCH 0/3] gpu: ion: oom killer

by Zhangfei Gao

v0->v1: 1, Change gen_pool_create(12, -1) to gen_pool_create(PAGE_SHIFT, -1), suggested by Haojian 2. move ion_shrink out of mutex, suggested by Nishanth 3. check error flag of ERR_PTR(-ENOMEM) 4. add msleep to allow schedule out. Base on common.git, android-3.4 branch Patch 2: Add support page wised cache flush for carveout_heap There is only one nents for carveout heap, as well as dirty bit. As a result, cache flush only takes effect for total carve heap. Patch 3: Add oom killer. Once heap is used off, SIGKILL is send to all tasks refered the buffer with descending oom_socre_adj Zhangfei Gao (3): gpu: ion: update carveout_heap_ops gpu: ion: carveout_heap page wised cache flush gpu: ion: oom killer drivers/gpu/ion/ion.c | 118 +++++++++++++++++++++++++++++++++- drivers/gpu/ion/ion_carveout_heap.c | 25 ++++++-- 2 files changed, 133 insertions(+), 10 deletions(-)

12 years, 10 months

[GIT PULL] DMA-mapping fixes for v3.6

by Marek Szyprowski

Hi Linus, I would like to ask for pulling another set of fixes for ARM dma-mapping subsystem. Commit e9da6e9905e6 replaced custom consistent buffer remapping code with generic vmalloc areas. It however introduced some regressions caused by limited support for allocations in atomic context. This series contains fixes for those regressions. For some subplatforms the default, pre-allocated pool for atomic allocations turned out to be too small, so a function for setting its size has been added. Another set of patches adds support for atomic allocations to IOMMU-aware DMA-mapping implementation. The last part of this pull request contains two fixes for Contiguous Memory Allocator, which relax too strict requirements. The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0: Linux 3.6-rc3 (2012-08-22 13:29:06 -0700) are available in the git repository at: fixes-for-3.6 for you to fetch changes up to 479ed93a4b98eef03fd8260f7ddc00019221c450: ARM: dma-mapping: IOMMU allocates pages from atomic_pool with GFP_ATOMIC (2012-08-28 21:01:07 +0200) Thanks! Best regards Marek Szyprowski Samsung Poland R&D Center ---------------------------------------------------------------- Patch summary: Hiroshi Doyu (4): ARM: dma-mapping: atomic_pool with struct page **pages ARM: dma-mapping: Refactor out to introduce __in_atomic_pool ARM: dma-mapping: Introduce __atomic_get_pages() for __iommu_get_pages() ARM: dma-mapping: IOMMU allocates pages from atomic_pool with GFP_ATOMIC Marek Szyprowski (5): mm: cma: fix alignment requirements for contiguous regions ARM: relax conditions required for enabling Contiguous Memory Allocator ARM: DMA-Mapping: add function for setting coherent pool size from platform code ARM: DMA-Mapping: print warning when atomic coherent allocation fails ARM: Kirkwood: increase atomic coherent pool size arch/arm/Kconfig | 2 +- arch/arm/include/asm/dma-mapping.h | 7 ++ arch/arm/mach-kirkwood/common.c | 7 ++ arch/arm/mm/dma-mapping.c | 114 ++++++++++++++++++++++++++++++++--- drivers/base/dma-contiguous.c | 2 +- 5 files changed, 120 insertions(+), 12 deletions(-)

12 years, 10 months

Exporting ion buffer to multiple process from same driver

by Nishanth Peethambaran

Hi, I am trying to export an ion_buffer allocate from kernel space to multiple user-space clients. Eg: Allow multiple process to mmap framebuffer allocated using ion by fb driver. The following is the pseudo-code for that. Is this fine? there a cleaner way to do it? Or is it expected to share buffers across process only by user-space sharing fds using sockets/binder and not directly in kernel. fb driver init/probe: (init process context) ------------------------------------------------- /* Create an ion client and allocate framebuffer */ init_client = ion_client_create(idev,...); init_hdl = ion_alloc(init_client,...); /* Create a global dma_buf instance for the buffer */ fd = ion_share_dma_buf(init_client, init_hdl); // - Inc refcount of ion_buffer // - Create a dma_buf and anon-file for the ion buffer // - Get a free fd and install to anon file g_dma_buf = dma_buf_get(fd); // - Get the dma_buf pointer and inc refcount of anon_file dma_buf_put(g_dma_buf); // - Dec extra refcount of anon_file which happened in prev command put_unused_fd(fd); // - Free up the fd as fd is not exported to user-space here. fb driver exit: (init process context) ------------------------------------------ /* Free the dma_buf reference */ dma_buf_put(g_dma_buf); // - Dec refcount of anon_file. Free the dma_buf and dec refcount of ion_buffer if anon_file refcount = 0 /* Free the framebuffer and destroy the ion client created for init process */ ion_free(init_client, init_hdl); ion_client_destroy(init_client); fb device open: (user process context) ----------------------------------------------- /* Create an ion client for the user process */ p_client = ion_client_create(idev,...); fb device ioctl to import ion handle for the fb: (user process context) ----------------------------------------------------------------------------------- /* Import a ion_handle from the global dma_buf */ fd = dma_buf_fd(g_dmabuf, O_CLOEXEC); // - Get ref to anon file // - Get a free fd and install to anon file p_hdl = ion_import_dma_buf(p_client, fd); // - Inc refcount of ion_buffer // - create a ion_handle for the buffer for this process/client dma_buf_put(g_dmabuf); // - Free the anon file reference taken in first step put_unused_fd(fd); // - Free up the fd as fd is not exported to user-space here. fb device release: (user process context) --------------------------------------------------- /* Destroy the client created */ ion_client_destroy(p_client); - Nishanth Peethambaran

12 years, 10 months

CMA page migration failure due to buffers on bh_lru

by Laura Abbott

Hi, I've been observing a high rate of failures with CMA allocations on my ARM system. I've set up a test case set up with a 56MB CMA region that essentially does the following: total_failures = 0; loop forever: loop_failure = 0; for (i = 0; i < 56; i++) chunk[i] = dma_allocate(&cma_dev, 1MB) if (!chunk[i]) loop_failure = 0 if (loop_failure) total_failures++ loop_failure = 0 for (i = 0; i < 56; i++) dma_free(&cma_dev, chunk[i], 1MB) In the background, I also have a process doing some amount of filesystem activity (adb push/pull since this is an android system). During the course of my investigations I generally get ~8500 loops total and ~450 total failures (i.e. one or more buffers could not be allocated). This is unacceptably high for our use cases. In every case the allocation failure was ultimately due to a migration failure; the pages contained buffers which could not be dropped because the buffers were busy (move_to_new_page -> fallback_migrate_page -> try_to_release_page -> try_to_free_buffers -> drop_buffers -> buffer_busy). In every case, the b_count on the buffer head was always 1. The problem arises because of the LRU lists for buffer heads: __getblk __getblk_slow grow_buffers grow_dev_page find_or_create_page -- create a possibly movable page __find_get_block __find_get_block_slow find_get_page -- return the movable page bh_lru_install get_bh -- buffer head now has a reference The reference taken in bh_lru_install won't be dropped until the bh is evicted from the lru. This means the page cannot be migrated as long as the buffer exists on an LRU list. The real issue is that unless the buffer gets evicted quickly the page can remain non-migratible for long periods of time. This makes CMA regions unusable for long periods of time given that we generally don't want to size CMA regions any larger than necessary ergo any failure will cause a problem. My quick and dirty workaround for testing is to remove the GFP_MOVABLE flag from find_or_create_page but this seems significantly less than optimal. Ideally, it seems like the buffers should be evicted from the LRU when trying to drop (expand on invalid_bh_lru?) but I'm not familiar enough with the code path to know if this is a good approach. Any suggestions/feedback is appreciated. Thanks. Laura -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

12 years, 10 months

[linaro-mm-sig] Backward compatibility of 3.4 android kernel to ICS

by Nishanth Peethambaran

Hi, I see that the lowmemkiller.c is changed to use oom_score_adj instead of oom_adj. Does this mean I cannot use an ICS system image with 3.4 kernel? Or is there a workaround? - Nishanth Peethambaran

12 years, 10 months

Re: [Linaro-mm-sig] CMA allocation issue : some pages can't be migrated

by Aubertin, Guillaume

looping-in the linaro-mm-sig ML. On Thu, Aug 30, 2012 at 4:47 PM, Aubertin, Guillaume <g-aubertin(a)ti.com>wrote: > hi guys, > > I've been working for a few days on getting a proper rmmod with the > remoteproc/rpmsg modules, and I stumbled upon an interesting issue. > > when doing sucessive memory allocation and release in the CMA > reservation (by loading/unloading the firmware several times), the > following message shows up : > > [ 119.908477] cma: dma_alloc_from_contiguous(cma ed10ad00, count 256, > align 8) > [ 119.908843] cma: dma_alloc_from_contiguous(): memory range at c0dfb000 > is busy, retrying > [ 119.909698] cma: dma_alloc_from_contiguous(): returned c0dfd000 > > dma_alloc_from_contiguous() tries to allocate the following range, > 0xc0dfd000, succesfully this time. > > In some cases, the allocation fails after trying several ranges : > > [ 119.912231] cma: dma_alloc_from_contiguous(cma ed10ad00, count 768, > align 8) > [ 119.912719] cma: dma_alloc_from_contiguous(): memory range at c0dff000 > is busy, retrying > [ 119.913055] cma: dma_alloc_from_contiguous(): memory range at c0e01000 > is busy, retrying > [ 119.913055] rproc remoteproc0: dma_alloc_coherent failed: 3145728 > > Here is my understanding so far : > > First, even if we made a CMA reservation, the kernel can still allocate > pages in this area, but these pages must be movable (user process page by > example). > > When dma_alloc_from_contiguous() is called to allocate X pages, it looks > for the next X contiguous free pages in it's CMA bitmap (with respect to > the memory alignment). Then, alloc_contig_range() is called to allocate the > given range of pages. Alloc_contig_range() analyses the pages we want to > allocate, and if a page is already used, it is migrated to a new page > outside the page array we want to reserve. this is done using > isolate_migratepages_range() to list the pages to migrate, and > migrate_pages() to try to migrate the pages, and that's where it fails. > Below is a list of next function calls : > > fallback_migrate_page() --> migrate_page() --> try_to_release_page() > --> try_to_free_buffer() --> drop_buffers() --> buffer_busy() > > I understand here that the page contains used buffers that can't be > dropped, and so the page can't be migrated. Well, I must admit that once > here, I'm feeling a little lost in this ocean of memory management code ;). > After a few researches, I found the following thread on the > linux-arm-kernel ML talking about the same issue : > > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/102844.html with > the following patch : > > * mm/page_alloc.c | 3 ++-* > * 1 files changed, 2 insertions(+), 1 deletions(-)* > * > * > *diff --git a/mm/page_alloc.c b/mm/page_alloc.c* > *index 0e1c6f5..c9a6483 100644* > *--- a/mm/page_alloc.c* > *+++ b/mm/page_alloc.c* > *@@ -1310,7 +1310,8 @@ void free_hot_cold_page(struct page *page, int > cold)* > * * excessively into the page allocator* > * */* > * if (migratetype >= MIGRATE_PCPTYPES) {* > *- if (unlikely(migratetype == MIGRATE_ISOLATE)) {* > *+ if (unlikely(migratetype == MIGRATE_ISOLATE)* > *+ || is_migrate_cma(migratetype)) {* > * free_one_page(zone, page, 0, migratetype);* > * goto out;* > * }* > > I tried the patch, and it seems to work (I didn't have any "memory range > busy" in 5000+ tests), but I'm affraid that this could have some nasty side > effects. > > Any idea ? > > Thanks in advance, > Guillaume > > > -- > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve > Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 > -- Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

12 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig