Linaro-mm-sig May 2013

linaro-mm-sig@lists.linaro.org

14 participants
8 discussions

[PATCH v4 0/4] add mutex wait/wound/style style locks

by Maarten Lankhorst

Version 4 already? Small api changes since v3: - Remove ww_mutex_unlock_single and ww_mutex_lock_single. - Rename ww_mutex_trylock_single to ww_mutex_trylock. - Remove separate implementations of ww_mutex_lock_slow*, normal functions can be used. Inline versions still exist for extra debugging, and to annotate. - Cleanup unneeded memory barriers, add comment to the remaining smp_mb(). Thanks to Daniel Vetter, Rob Clark and Peter Zijlstra for their feedback. --- Daniel Vetter (1): mutex: w/w mutex slowpath debugging Maarten Lankhorst (3): arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not. mutex: add support for wound/wait style locks, v5 mutex: Add ww tests to lib/locking-selftest.c. v4 Documentation/ww-mutex-design.txt | 344 +++++++++++++++++++++++++++++++ arch/ia64/include/asm/mutex.h | 10 - arch/powerpc/include/asm/mutex.h | 10 - arch/sh/include/asm/mutex-llsc.h | 4 arch/x86/include/asm/mutex_32.h | 11 - arch/x86/include/asm/mutex_64.h | 11 - include/asm-generic/mutex-dec.h | 10 - include/asm-generic/mutex-null.h | 2 include/asm-generic/mutex-xchg.h | 10 - include/linux/mutex-debug.h | 1 include/linux/mutex.h | 363 +++++++++++++++++++++++++++++++++ kernel/mutex.c | 384 ++++++++++++++++++++++++++++++++--- lib/Kconfig.debug | 13 + lib/debug_locks.c | 2 lib/locking-selftest.c | 410 +++++++++++++++++++++++++++++++++++-- 15 files changed, 1492 insertions(+), 93 deletions(-) create mode 100644 Documentation/ww-mutex-design.txt -- ~Maarten

11 years, 6 months

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

by Seung-Woo Kim

importer private data in dma-buf attachment can be used by importer to reimport same dma-buf. Seung-Woo Kim (2): dma-buf: add importer private data to attachment drm/prime: find gem object from the reimported dma-buf drivers/base/dma-buf.c | 31 ++++++++++++++++++++++++++++ drivers/gpu/drm/drm_prime.c | 19 ++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 + drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 + drivers/gpu/drm/udl/udl_gem.c | 1 + include/linux/dma-buf.h | 4 +++ 6 files changed, 52 insertions(+), 5 deletions(-) -- 1.7.4.1

11 years, 6 months

[PATCH v3 0/3] Wait/wound mutex implementation, v3

by Maarten Lankhorst

The following series implements the updated api for wait/wound mutex locks. The documentation and api should be complete, the implementation may not be final. There is no support for -rt yet, and TASK_DEADLOCK handling is missing too. However I believe that this is an implementation detail, and that the interface for users of the api will not behave differently. ww_acquire_ctx has been added, and a whole lot of api abuses are now correctly detected because of the extra state carried in ww_acquire_ctx if debugging is enabled. --- Maarten Lankhorst (3): arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not. mutex: add support for wound/wait style locks, v3 mutex: Add ww tests to lib/locking-selftest.c. v3 Documentation/ww-mutex-design.txt | 322 +++++++++++++++++++++++++ arch/ia64/include/asm/mutex.h | 10 - arch/powerpc/include/asm/mutex.h | 10 - arch/sh/include/asm/mutex-llsc.h | 4 arch/x86/include/asm/mutex_32.h | 11 - arch/x86/include/asm/mutex_64.h | 11 - include/asm-generic/mutex-dec.h | 10 - include/asm-generic/mutex-null.h | 2 include/asm-generic/mutex-xchg.h | 10 - include/linux/mutex-debug.h | 1 include/linux/mutex.h | 257 ++++++++++++++++++++ kernel/mutex.c | 473 ++++++++++++++++++++++++++++++++++--- lib/debug_locks.c | 2 lib/locking-selftest.c | 439 +++++++++++++++++++++++++++++++++- 14 files changed, 1469 insertions(+), 93 deletions(-) create mode 100644 Documentation/ww-mutex-design.txt -- Signature

11 years, 7 months

[PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

by Marek Szyprowski

dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless the flags provided by the caller. This causes excessive pruning of emergency memory pools without any good reason. This patch changes the code to correctly use gfp flags provided by the dmapool caller. This should solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA allocations can be served only from the special, very limited memory pool. Reported-by: Soren Moch <smoch(a)web.de> Reported-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- mm/dmapool.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index c5ab33b..86de9b2 100644 --- a/mm/dmapool.c +++ b/mm/dmapool.c @@ -62,8 +62,6 @@ struct dma_page { /* cacheable header for 'allocation' bytes */ unsigned int offset; }; -#define POOL_TIMEOUT_JIFFIES ((100 /* msec */ * HZ) / 1000) - static DEFINE_MUTEX(pools_lock); static ssize_t @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) memset(page->vaddr, POOL_POISON_FREED, pool->allocation); #endif pool_initialise_page(pool, page); - list_add(&page->page_list, &pool->page_list); page->in_use = 0; page->offset = 0; } else { @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags, might_sleep_if(mem_flags & __GFP_WAIT); spin_lock_irqsave(&pool->lock, flags); - restart: list_for_each_entry(page, &pool->page_list, page_list) { if (page->offset < pool->allocation) goto ready; } - page = pool_alloc_page(pool, GFP_ATOMIC); - if (!page) { - if (mem_flags & __GFP_WAIT) { - DECLARE_WAITQUEUE(wait, current); - __set_current_state(TASK_UNINTERRUPTIBLE); - __add_wait_queue(&pool->waitq, &wait); - spin_unlock_irqrestore(&pool->lock, flags); + /* pool_alloc_page() might sleep, so temporarily drop &pool->lock */ + spin_unlock_irqrestore(&pool->lock, flags); - schedule_timeout(POOL_TIMEOUT_JIFFIES); + page = pool_alloc_page(pool, mem_flags); + if (!page) + return NULL; - spin_lock_irqsave(&pool->lock, flags); - __remove_wait_queue(&pool->waitq, &wait); - goto restart; - } - retval = NULL; - goto done; - } + spin_lock_irqsave(&pool->lock, flags); + list_add(&page->page_list, &pool->page_list); ready: page->in_use++; offset = page->offset; @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags, #ifdef DMAPOOL_DEBUG memset(retval, POOL_POISON_ALLOCATED, pool->size); #endif - done: spin_unlock_irqrestore(&pool->lock, flags); return retval; } -- 1.7.9.5

11 years, 7 months

[RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages()

by Marek Szyprowski

Hello, Contiguous Memory Allocator is very sensitive about migration failures of the individual pages. A single page, which causes permanent migration failure can break large conitguous allocations and cause the failure of a multimedia device driver. One of the known issues with migration of CMA pages are the problems of migrating the anonymous user pages, for which the others called get_user_pages(). This takes a reference to the given user pages to let kernel to operate directly on the page content. This is usually used for preventing swaping out the page contents and doing direct DMA to/from userspace. To solving this issue requires preventing locking of the pages, which are placed in CMA regions, for a long time. Our idea is to migrate anonymous page content before locking the page in get_user_pages(). This cannot be done automatically, as get_user_pages() interface is used very often for various operations, which usually last for a short period of time (like for example exec syscall). We have added a new flag indicating that the given get_user_space() call will grab pages for a long time, thus it is suitable to use the migration workaround in such cases. The proposed extensions is used by V4L2/VideoBuf2 (drivers/media/v4l2-core/videobuf2-dma-contig.c), but that is not the only place which might benefit from it, like any driver which use DMA to userspace with get_user_pages(). This one is provided to demonstrate the use case. I would like to hear some comments on the presented approach. What do you think about it? Is there a chance to get such workaround merged at some point to mainline? Best regards Marek Szyprowski Samsung Poland R&D Center Patch summary: Marek Szyprowski (5): mm: introduce migrate_replace_page() for migrating page to the given target mm: get_user_pages: use static inline mm: get_user_pages: use NON-MOVABLE pages when FOLL_DURABLE flag is set mm: get_user_pages: migrate out CMA pages when FOLL_DURABLE flag is set media: vb2: use FOLL_DURABLE and __get_user_pages() to avoid CMA migration issues drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 +- include/linux/highmem.h | 12 ++- include/linux/migrate.h | 5 + include/linux/mm.h | 76 ++++++++++++- mm/internal.h | 12 +++ mm/memory.c | 136 +++++++++++------------- mm/migrate.c | 59 ++++++++++ 7 files changed, 225 insertions(+), 83 deletions(-) -- 1.7.9.5

11 years, 7 months

Re: [Linaro-mm-sig] [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

by Daniel Vetter

On Wed, May 1, 2013 at 6:30 AM, Dave Airlie <airlied(a)gmail.com> wrote: > Since we ask the dmabuf owner to map the dma-buf into our device > address space, but for udl at present that is the CPU address space, > since we don't DMA directly from the mapped buffer. > > However if we don't set a dma mask on the usb device, the mapping > ends up using swiotlb on machines that have it enabled, which > is less than desireable. > > Signed-off-by: Dave Airlie <airlied(a)redhat.com> Fyi for everyone else who was not on irc when Dave&I discussed this: This really shouldn't be required and I think the real issue is that udl creates a dma_buf attachement (which is needed for device dma only), but only really wants to do cpu access through vmap/kmap. So not attached the device should be good enough. Cc'ing a few more lists for better fyi ;-) -Daniel > --- > drivers/gpu/drm/udl/udl_main.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c > index 0ce2d71..6770e1b 100644 > --- a/drivers/gpu/drm/udl/udl_main.c > +++ b/drivers/gpu/drm/udl/udl_main.c > @@ -293,6 +293,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long flags) > udl->ddev = dev; > dev->dev_private = udl; > > + dma_set_mask(dev->dev, DMA_BIT_MASK(64)); > if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) { > DRM_ERROR("firmware not recognized. Assume incompatible device\n"); > goto err; > -- > 1.8.2 > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

11 years, 7 months

RFC: Unified DMA allocation algorithms

by Laura Abbott

Hi all, I've been looking at a better way to do custom dma allocation algorithms in a similar style to Ion heaps. Most drivers/clients have come up with a series of semi-standard ways to get memory (CMA, memblock_reserve, discontiguous pages etc.) . As these allocation schemes get more and more complex, there needs to be a since place where all clients (Ion based driver vs. DRM driver vs. ???) can independently take advantage of any optimizations and call a single API for the backing allocations. The dma_map_ops take care of almost everything needed for abstraction but the question is where should new allocation algorithms be located? Most of the work has been added to either arm/mm/dma-mapping.c or dma-contiguous.c . My current thought: 1) split out the dma_map_ops currently in dma-mapping.c into separate files (dma-mapping-common.c, dma-mapping-iommu.c) 2) Extend dma-contiguous.c to support memblock_reserve memory 3) Place additional algorithms in either arch/arm/mm or drivers/base/dma-alloc/ as appropriate to the code. This is the part where I'm most unsure about the direction. I don't have anything written yet but I plan to draft some patches assuming the proposed approach sounds reasonable and no one else has started on something similar already. Thoughts? Opinions? Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

11 years, 7 months

[GIT PULL]: dma-buf updates for 3.10

by Sumit Semwal

Hi Linus, The 3.10 pull request for dma-buf framework updates: small one, could you please pull? Thanks and best regards, ~Sumit. The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f: Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/tag-for-linus-3.10 for you to fetch changes up to b89e35636bc75b72d15a1af6d49798802aff77d5: dma-buf: Add debugfs support (2013-05-01 16:36:22 +0530) ---------------------------------------------------------------- 3.10 dma-buf updates Added debugfs support to dma-buf. ---------------------------------------------------------------- Sumit Semwal (2): dma-buf: replace dma_buf_export() with dma_buf_export_named() dma-buf: Add debugfs support Documentation/dma-buf-sharing.txt | 13 ++- drivers/base/dma-buf.c | 169 +++++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 16 +++- 3 files changed, 189 insertions(+), 9 deletions(-)

11 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig May 2013