by Liam Mark

[permalink] [raw]

Subject: Re: [RFC][PATCH 0/6 v3] DMA-BUF Heaps (destaging ION)

On Fri, 29 Mar 2019, Andrew F. Davis wrote:

> On 3/28/19 7:15 PM, John Stultz wrote:
> > Here is another RFC of the dma-buf heaps patchset Andrew and I
> > have been working on which tries to destage a fair chunk of ION
> > functionality.
> >
> > The patchset implements per-heap devices which can be opened
> > directly and then an ioctl is used to allocate a dmabuf from the
> > heap.
> >
> > The interface is similar, but much simpler then IONs, only
> > providing an ALLOC ioctl.
> >
> > Also, I've provided simple system and cma heaps. The system
> > heap in particular is missing the page-pool optimizations ION
> > had, but works well enough to validate the interface.
> >
> > I've booted and tested these patches with AOSP on the HiKey960
> > using the kernel tree here:
> > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> >
> > And the userspace changes here:
> > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> >
> >
> > Compared to ION, this patchset is missing the system-contig,
> > carveout and chunk heaps, as I don't have a device that uses
> > those, so I'm unable to do much useful validation there.
> > Additionally we have no upstream users of chunk or carveout,
> > and the system-contig has been deprecated in the common/andoid-*
> > kernels, so this should be ok.
> >
>
>
> I'd like to go over my use-cases for a moment to see if we can get some
> agreement on what to do with the carveout/chunk heaps.
>
> We used DRM (omapdrm) to get buffers for display, GPU, and multi-media.
> Our out-of-tree CMEM driver[0] for remote processing (OpenCL/CV/VX)
> buffers. And for secure heaps we use what are basically slightly
> modified ION carveout heaps.
>
> Now with the DMA-Heap framework what we can do is for sub-systems with
> IOMMUs use 'system' heap (GPU). For those that need contiguous memory
> (display, MM) we have 'cma' heap (and maybe 'system-contig' at some
> point). For our SRAM areas used in remote processing I've posted an RFC
> for a heap[1] to provide allocations from those areas.
>
> The above leaves one last gap for us, uncached/unmapped areas from
> regular memory. I propose this is where we use the 'carveout' heap.
> Right now to get some contiguous/cached memory with DT you can:
>
> reserved-memory {
> [...]
> cma_memory {
> compatible = "shared-dma-pool";
> reg = <0x79000000 0x400000>;
> reusable;
> };
>
> coherent_memory@78000000 {
> reg = <0x78000000 0x800000>;
> no-map;
> };
> };
>
> 'cma_memory' will show up as a 'cma' heap, so all good there.
>
> Looking at 'coherent_memory' it will not have valid backing 'struct
> page' and so cannot be given cached mappings as the standard dma memory
> ops would fail. This would give this area the right properties for both
> users who don't want to do all the cache maintenance ops (Liam?) and for
> secure heaps that have restrictions on access from Linux running CPU.
>

So our main use case in which we use uncached memory to avoid cache
maintenance is for multimedia memory (which is generally only accessed by
devices), there can be both a lot of this memory allocated for these use
cases and the amount varies so a carveout wouldn't work for us.
However I am still holding out hope that we will be able to drop this
requirement for uncached memory through changes to both Android and
ION/dma-buf heaps, such as the proposal where Android keeps devices
attached and ION/dma-buf heaps track of which buffers are 'dirty'.
Investigations still ongoing...

We have a number of use cases which use uncached memory, the major reason
that our clients use uncached is for the performance benefit above. I
am currently doing a review of client use cases to determine all our
uncached requirements, for example if CMA heaps will need to support
uncached allocations, once that is done I will be able to better
articulate our requirements.

One use case where I have seen carveouts uses which doesn't sound like it
would be supported under the current proposals is when clients need to
allocate a lot of cached memory quickly.
I have seen cases where a large carveout is used for camera use cases.
Basically they allocate cached memory from the carveout and any extra
memory they need (after the carveout is full) is allocated from the system
heap.

This allows for memory heavy performance sensitive apps, such as camera,
to be launched quickly.

> The question then is how to mark these areas for export with DMA-Heaps?
> Maybe a cma_for_each_area() like function but for dma coherent areas?
>

That sounds reasonable to me.

> Anyway for now this is not super important and I can post a patchset at
> some later point for this when I get it working and tested internally.
>
> [0]
> http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_CMEM.html
> [1] https://patchwork.kernel.org/patch/10863957/
>
> Thanks,
> Andrew
>
>
> > I've also removed the stats accounting for now, since it should
> > be implemented by the heaps themselves.
> >
> >
> > New in v3:
> > * Proper /dev/heap/* names on both Android and classic Linux
> > environments
> > * Major rework of the helper code from Andrew
> > * Dummy test device added to test importing
> > * *Lots* of cleanups suggested by many (thank you for all the
> > input)!
> >
> >
> > Outstanding concerns:
> > * Potential need for private flags in interface for secure
> > heaps. Need to better understand secure heap usage.
> > * Making sure the performance issues from potentially unnecessary
> > cache-management operations can be resolved properly for system
> > and cma heaps (outstanding issue from ION).
> >
> >
> > Eventual TODOS:
> > * Sanity filtering for heap names
> > * Reimplement performance optimizations for system heap
> > * Add stats accounting to system/cma heaps
> > * Make the kselftest more useful
> > * Add other heaps folks see as useful (would love to get
> > some help from actual carveout/chunk users)!
> >
> > That said, the main user-interface is shaping up and I wanted
> > to get some input on the device model (particularly from GreKH)
> > and any other API/ABI specific input.
> >
> > thanks
> > -john
> >
> > Cc: Laura Abbott <[email protected]>
> > Cc: Benjamin Gaignard <[email protected]>
> > Cc: Sumit Semwal <[email protected]>
> > Cc: Liam Mark <[email protected]>
> > Cc: Pratik Patel <[email protected]>
> > Cc: Brian Starkey <[email protected]>
> > Cc: Vincent Donnefort <[email protected]>
> > Cc: Sudipto Paul <[email protected]>
> > Cc: Andrew F. Davis <[email protected]>
> > Cc: Xu YiPing <[email protected]>
> > Cc: "Chenfeng (puck)" <[email protected]>
> > Cc: butao <[email protected]>
> > Cc: "Xiaqing (A)" <[email protected]>
> > Cc: Yudongbin <[email protected]>
> > Cc: Christoph Hellwig <[email protected]>
> > Cc: Chenbo Feng <[email protected]>
> > Cc: Alistair Strachan <[email protected]>
> > Cc: [email protected]
> >
> > Andrew F. Davis (2):
> > dma-buf: Add dma-buf heaps framework
> > dma-buf: Add Dummy Importer Test Device
> >
> > John Stultz (4):
> > dma-buf: heaps: Add heap helpers
> > dma-buf: heaps: Add system heap to dmabuf heaps
> > dma-buf: heaps: Add CMA heap to dmabuf heapss
> > kselftests: Add dma-heap test
> >
> > MAINTAINERS | 18 ++
> > drivers/dma-buf/Kconfig | 16 ++
> > drivers/dma-buf/Makefile | 3 +
> > drivers/dma-buf/dma-buf-testdev.c | 239 +++++++++++++++++++
> > drivers/dma-buf/dma-heap.c | 234 ++++++++++++++++++
> > drivers/dma-buf/heaps/Kconfig | 14 ++
> > drivers/dma-buf/heaps/Makefile | 4 +
> > drivers/dma-buf/heaps/cma_heap.c | 170 ++++++++++++++
> > drivers/dma-buf/heaps/heap-helpers.c | 261 +++++++++++++++++++++
> > drivers/dma-buf/heaps/heap-helpers.h | 55 +++++
> > drivers/dma-buf/heaps/system_heap.c | 120 ++++++++++
> > include/linux/dma-heap.h | 58 +++++
> > include/uapi/linux/dma-buf-testdev.h | 37 +++
> > include/uapi/linux/dma-heap.h | 52 ++++
> > tools/testing/selftests/dmabuf-heaps/Makefile | 11 +
> > tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 169 +++++++++++++
> > 16 files changed, 1461 insertions(+)
> > create mode 100644 drivers/dma-buf/dma-buf-testdev.c
> > create mode 100644 drivers/dma-buf/dma-heap.c
> > create mode 100644 drivers/dma-buf/heaps/Kconfig
> > create mode 100644 drivers/dma-buf/heaps/Makefile
> > create mode 100644 drivers/dma-buf/heaps/cma_heap.c
> > create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
> > create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
> > create mode 100644 drivers/dma-buf/heaps/system_heap.c
> > create mode 100644 include/linux/dma-heap.h
> > create mode 100644 include/uapi/linux/dma-buf-testdev.h
> > create mode 100644 include/uapi/linux/dma-heap.h
> > create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
> > create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> >
>

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

2019-04-01 08:03:01

by Benjamin Gaignard

[permalink] [raw]

Subject: Re: [RFC][PATCH 4/6 v3] dma-buf: heaps: Add CMA heap to dmabuf heapss

Le ven. 29 mars 2019 à 16:42, Andrew F. Davis <[email protected]> a écrit :
>
> On 3/29/19 10:30 AM, Benjamin Gaignard wrote:
> > Le ven. 29 mars 2019 à 16:19, Andrew F. Davis <[email protected]> a écrit :
> >>
> >> On 3/29/19 9:44 AM, Benjamin Gaignard wrote:
> >>> Le ven. 29 mars 2019 à 01:16, John Stultz <[email protected]> a écrit :
> >>>>
> >>>> This adds a CMA heap, which allows userspace to allocate
> >>>> a dma-buf of contiguous memory out of a CMA region.
> >>>>
> >>>> This code is an evolution of the Android ION implementation, so
> >>>> thanks to its original author and maintainters:
> >>>> Benjamin Gaignard, Laura Abbott, and others!
> >>>>
> >>>> Cc: Laura Abbott <[email protected]>
> >>>> Cc: Benjamin Gaignard <[email protected]>
> >>>> Cc: Sumit Semwal <[email protected]>
> >>>> Cc: Liam Mark <[email protected]>
> >>>> Cc: Pratik Patel <[email protected]>
> >>>> Cc: Brian Starkey <[email protected]>
> >>>> Cc: Vincent Donnefort <[email protected]>
> >>>> Cc: Sudipto Paul <[email protected]>
> >>>> Cc: Andrew F. Davis <[email protected]>
> >>>> Cc: Xu YiPing <[email protected]>
> >>>> Cc: "Chenfeng (puck)" <[email protected]>
> >>>> Cc: butao <[email protected]>
> >>>> Cc: "Xiaqing (A)" <[email protected]>
> >>>> Cc: Yudongbin <[email protected]>
> >>>> Cc: Christoph Hellwig <[email protected]>
> >>>> Cc: Chenbo Feng <[email protected]>
> >>>> Cc: Alistair Strachan <[email protected]>
> >>>> Cc: [email protected]
> >>>> Signed-off-by: John Stultz <[email protected]>
> >>>> ---
> >>>> v2:
> >>>> * Switch allocate to return dmabuf fd
> >>>> * Simplify init code
> >>>> * Checkpatch fixups
> >>>> v3:
> >>>> * Switch to inline function for to_cma_heap()
> >>>> * Minor cleanups suggested by Brian
> >>>> * Fold in new registration style from Andrew
> >>>> * Folded in changes from Andrew to use simplified page list
> >>>> from the heap helpers
> >>>> ---
> >>>> drivers/dma-buf/heaps/Kconfig | 8 ++
> >>>> drivers/dma-buf/heaps/Makefile | 1 +
> >>>> drivers/dma-buf/heaps/cma_heap.c | 170 +++++++++++++++++++++++++++++++++++++++
> >>>> 3 files changed, 179 insertions(+)
> >>>> create mode 100644 drivers/dma-buf/heaps/cma_heap.c
> >>>>
> >>>> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> >>>> index 2050527..a5eef06 100644
> >>>> --- a/drivers/dma-buf/heaps/Kconfig
> >>>> +++ b/drivers/dma-buf/heaps/Kconfig
> >>>> @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
> >>>> help
> >>>> Choose this option to enable the system dmabuf heap. The system heap
> >>>> is backed by pages from the buddy allocator. If in doubt, say Y.
> >>>> +
> >>>> +config DMABUF_HEAPS_CMA
> >>>> + bool "DMA-BUF CMA Heap"
> >>>> + depends on DMABUF_HEAPS && DMA_CMA
> >>>> + help
> >>>> + Choose this option to enable dma-buf CMA heap. This heap is backed
> >>>> + by the Contiguous Memory Allocator (CMA). If your system has these
> >>>> + regions, you should say Y here.
> >>>> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> >>>> index d1808ec..6e54cde 100644
> >>>> --- a/drivers/dma-buf/heaps/Makefile
> >>>> +++ b/drivers/dma-buf/heaps/Makefile
> >>>> @@ -1,3 +1,4 @@
> >>>> # SPDX-License-Identifier: GPL-2.0
> >>>> obj-y += heap-helpers.o
> >>>> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> >>>> +obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> >>>> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
> >>>> new file mode 100644
> >>>> index 0000000..f4485c60
> >>>> --- /dev/null
> >>>> +++ b/drivers/dma-buf/heaps/cma_heap.c
> >>>> @@ -0,0 +1,170 @@
> >>>> +// SPDX-License-Identifier: GPL-2.0
> >>>> +/*
> >>>> + * DMABUF CMA heap exporter
> >>>> + *
> >>>> + * Copyright (C) 2012, 2019 Linaro Ltd.
> >>>> + * Author: <[email protected]> for ST-Ericsson.
> >>>> + */
> >>>> +
> >>>> +#include <linux/device.h>
> >>>> +#include <linux/dma-buf.h>
> >>>> +#include <linux/dma-heap.h>
> >>>> +#include <linux/slab.h>
> >>>> +#include <linux/errno.h>
> >>>> +#include <linux/err.h>
> >>>> +#include <linux/cma.h>
> >>>> +#include <linux/scatterlist.h>
> >>>> +#include <linux/highmem.h>
> >>>> +
> >>>> +#include "heap-helpers.h"
> >>>> +
> >>>> +struct cma_heap {
> >>>> + struct dma_heap *heap;
> >>>> + struct cma *cma;
> >>>> +};
> >>>> +
> >>>> +static void cma_heap_free(struct heap_helper_buffer *buffer)
> >>>> +{
> >>>> + struct cma_heap *cma_heap = dma_heap_get_data(buffer->heap_buffer.heap);
> >>>> + struct page *pages = buffer->priv_virt;
> >>>> + unsigned long nr_pages;
> >>>> +
> >>>> + nr_pages = buffer->heap_buffer.size >> PAGE_SHIFT;
> >>>> +
> >>>> + /* free page list */
> >>>> + kfree(buffer->pages);
> >>>> + /* release memory */
> >>>> + cma_release(cma_heap->cma, pages, nr_pages);
> >>>> + kfree(buffer);
> >>>> +}
> >>>> +
> >>>> +/* dmabuf heap CMA operations functions */
> >>>> +static int cma_heap_allocate(struct dma_heap *heap,
> >>>> + unsigned long len,
> >>>> + unsigned long flags)
> >>>> +{
> >>>> + struct cma_heap *cma_heap = dma_heap_get_data(heap);
> >>>> + struct heap_helper_buffer *helper_buffer;
> >>>> + struct page *pages;
> >>>> + size_t size = PAGE_ALIGN(len);
> >>>> + unsigned long nr_pages = size >> PAGE_SHIFT;
> >>>> + unsigned long align = get_order(size);
> >>>> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> >>>> + struct dma_buf *dmabuf;
> >>>> + int ret = -ENOMEM;
> >>>> + pgoff_t pg;
> >>>> +
> >>>> + if (align > CONFIG_CMA_ALIGNMENT)
> >>>> + align = CONFIG_CMA_ALIGNMENT;
> >>>> +
> >>>> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> >>>> + if (!helper_buffer)
> >>>> + return -ENOMEM;
> >>>> +
> >>>> + INIT_HEAP_HELPER_BUFFER(helper_buffer, cma_heap_free);
> >>>> + helper_buffer->heap_buffer.flags = flags;
> >>>> + helper_buffer->heap_buffer.heap = heap;
> >>>> + helper_buffer->heap_buffer.size = len;
> >>>> +
> >>>> + pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> >>>> + if (!pages)
> >>>> + goto free_buf;
> >>>> +
> >>>> + if (PageHighMem(pages)) {
> >>>> + unsigned long nr_clear_pages = nr_pages;
> >>>> + struct page *page = pages;
> >>>> +
> >>>> + while (nr_clear_pages > 0) {
> >>>> + void *vaddr = kmap_atomic(page);
> >>>> +
> >>>> + memset(vaddr, 0, PAGE_SIZE);
> >>>> + kunmap_atomic(vaddr);
> >>>> + page++;
> >>>> + nr_clear_pages--;
> >>>> + }
> >>>> + } else {
> >>>> + memset(page_address(pages), 0, size);
> >>>> + }
> >>>> +
> >>>> + helper_buffer->pagecount = nr_pages;
> >>>> + helper_buffer->pages = kmalloc_array(helper_buffer->pagecount,
> >>>> + sizeof(*helper_buffer->pages),
> >>>> + GFP_KERNEL);
> >>>> + if (!helper_buffer->pages) {
> >>>> + ret = -ENOMEM;
> >>>> + goto free_cma;
> >>>> + }
> >>>> +
> >>>> + for (pg = 0; pg < helper_buffer->pagecount; pg++) {
> >>>> + helper_buffer->pages[pg] = &pages[pg];
> >>>> + if (!helper_buffer->pages[pg])
> >>>> + goto free_pages;
> >>>> + }
> >>>> +
> >>>> + /* create the dmabuf */
> >>>> + exp_info.ops = &heap_helper_ops;
> >>>> + exp_info.size = len;
> >>>> + exp_info.flags = O_RDWR;
> >>>
> >>> I think that the flags should be provided when requesting the allocation
> >>> like it is done in DRM or V4L2.
> >>> For me DMA_HEAP_VALID_FLAGS = (O_CLOEXEC | O_ACCMODE).
> >>>
> >>
> >>
> >> So something like done in udmabuf?
> >>
> >> https://elixir.bootlin.com/linux/v5.1-rc1/source/include/uapi/linux/udmabuf.h#L8
> >>
> >> I think that can be arranged.
> >
> > I have in mind what is done by DRM:
> > https://elixir.bootlin.com/linux/v5.1-rc1/source/include/uapi/drm/drm.h#L707
> >
> > V4L2 does the same but without redefine the flags (which is better)
> >
>
> That would mean we would need a whole flag word passed in just for file
> flags when I only ever see one bit being useful(O_CLOEXEC or not). Do
> you see any situation where we need more than default O_RDWR and
> optional O_CLOEXEC for a dma-buf file?

Yes I really want a whole flag word because distinguish RD/WR only cases
could be useful to optimize cache maintenance (and later for secure heaps).

An other argument is that, few years ago, DRM doesn't allow at all O_RDWR
flag, but we manage to change this and make it possible.
So you believe that O_RDWR is mandatory will others O_RDWR is useless,
put it into a flag will make everybody happy :-)

Benjamin
>
> Andrew
>
> > Benjamin
> >
> >>
> >> John,
> >>
> >> This might be a good reason to move the dma_buf_fd() call below out of
> >> the heap and back into the core. That way the file exporting flags can
> >> be common and core handled. I don't think it would complicate the error
> >> handling any as we only need to dma_buf_put(dmabuf) in the core on
> >> failure and the heap specific cleanup will happen for us.
> >>
> >> Andrew
> >>
> >>
> >>> Benjamin
> >>>
> >>> Benjamin
> >>>
> >>>> + exp_info.priv = &helper_buffer->heap_buffer;
> >>>> + dmabuf = dma_buf_export(&exp_info);
> >>>> + if (IS_ERR(dmabuf)) {
> >>>> + ret = PTR_ERR(dmabuf);
> >>>> + goto free_pages;
> >>>> + }
> >>>> +
> >>>> + helper_buffer->heap_buffer.dmabuf = dmabuf;
> >>>> + helper_buffer->priv_virt = pages;
> >>>> +
> >>>> + ret = dma_buf_fd(dmabuf, O_CLOEXEC);
> >>>> + if (ret < 0) {
> >>>> + dma_buf_put(dmabuf);
> >>>> + /* just return, as put will call release and that will free */
> >>>> + return ret;
> >>>> + }
> >>>> +
> >>>> + return ret;
> >>>> +
> >>>> +free_pages:
> >>>> + kfree(helper_buffer->pages);
> >>>> +free_cma:
> >>>> + cma_release(cma_heap->cma, pages, nr_pages);
> >>>> +free_buf:
> >>>> + kfree(helper_buffer);
> >>>> + return ret;
> >>>> +}
> >>>> +
> >>>> +static struct dma_heap_ops cma_heap_ops = {
> >>>> + .allocate = cma_heap_allocate,
> >>>> +};
> >>>> +
> >>>> +static int __add_cma_heap(struct cma *cma, void *data)
> >>>> +{
> >>>> + struct cma_heap *cma_heap;
> >>>> + struct dma_heap_export_info exp_info;
> >>>> +
> >>>> + cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL);
> >>>> + if (!cma_heap)
> >>>> + return -ENOMEM;
> >>>> + cma_heap->cma = cma;
> >>>> +
> >>>> + exp_info.name = cma_get_name(cma);
> >>>> + 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;
> >>>> + }
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>> +
> >>>> +static int add_cma_heaps(void)
> >>>> +{
> >>>> + cma_for_each_area(__add_cma_heap, NULL);
> >>>> + return 0;
> >>>> +}
> >>>> +device_initcall(add_cma_heaps);
> >>>> --
> >>>> 2.7.4
> >>>>