Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1563720 > unrolled thread

[RFC simple allocator v1 0/2] Simple allocator

Back to article view | Back to linux.kernel

Contents

  [RFC simple allocator v1 0/2] Simple allocator Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-01-20 16:40 +0100
    [RFC simple allocator v1 2/2] add CMA simple allocator module Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-01-20 16:40 +0100
    Re: [RFC simple allocator v1 0/2] Simple allocator Daniel Vetter <daniel@ffwll.ch> - 2017-01-23 09:40 +0100
      Re: [RFC simple allocator v1 0/2] Simple allocator Laura Abbott <labbott@redhat.com> - 2017-01-25 10:20 +0100

#1563720 — [RFC simple allocator v1 0/2] Simple allocator

The goal of this RFC is to understand if a common ioctl for specific memory
regions allocations is needed/welcome.

Obviously it will not replace allocation done in linux kernel frameworks like
v4l2, drm/kms or others, but offer an alternative when you don't want/need to
use them for buffer allocation.
To keep a compatibility with what already exist allocated buffers are exported
in userland as dmabuf file descriptor (like ION is doing).

"Unix Device Memory Allocator" project [1] wants to create a userland library
which may allow to select, depending of the devices constraint, the best
back-end for allocation. With this RFC I would to propose to have common ioctl
for a maximum of allocators to avoid to duplicated back-ends for this library.

One of the issues that lead me to propose this RFC it is that since the beginning
it is a problem to allocate contiguous memory (CMA) without using v4l2 or
drm/kms so the first allocator available in this RFC use CMA memory.

An other question is: do we have others memory regions that could be interested
by this new framework ? I have in mind that some title memory regions could use
it or replace ION heaps (system, carveout, etc...).
Maybe it only solve CMA allocation issue, in this case there is no need to create
a new framework but only a dedicated ioctl.

Maybe the first thing to do is to change the name and the location of this 
module, suggestions are welcome.

I have testing this code with the following program:

#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>

#include "simple-allocator.h"

#define LENGTH 1024*16

void main (void)
{
	struct simple_allocate_data data;
	int fd = open("/dev/cma0", O_RDWR, 0);
	int ret;
	void *mem;

	if (fd < 0) {
		printf("Can't open /dev/cma0\n");
		return;
	}

	memset(&data, 0, sizeof(data));

	data.length = LENGTH;
	data.flags = O_RDWR | O_CLOEXEC;

	ret = ioctl(fd, SA_IOC_ALLOC, &data);
	if (ret) {
		printf("Buffer allocation failed\n");
		goto end;
	}

	mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
	if (mem == MAP_FAILED) {
		printf("mmap failed\n");
	}

	memset(mem, 0xFF, LENGTH);
	munmap(mem, LENGTH);

	printf("test simple allocator CMA OK\n");
end:
	close(fd);
}

[1] https://github.com/cubanismo/allocator

Benjamin Gaignard (2):
  Create Simple Allocator module
  add CMA simple allocator module

 Documentation/simple-allocator.txt              |  81 ++++++++++
 drivers/Kconfig                                 |   2 +
 drivers/Makefile                                |   1 +
 drivers/simpleallocator/Kconfig                 |  17 +++
 drivers/simpleallocator/Makefile                |   2 +
 drivers/simpleallocator/simple-allocator-cma.c  | 187 ++++++++++++++++++++++++
 drivers/simpleallocator/simple-allocator-priv.h |  33 +++++
 drivers/simpleallocator/simple-allocator.c      | 180 +++++++++++++++++++++++
 include/uapi/linux/simple-allocator.h           |  35 +++++
 9 files changed, 538 insertions(+)
 create mode 100644 Documentation/simple-allocator.txt
 create mode 100644 drivers/simpleallocator/Kconfig
 create mode 100644 drivers/simpleallocator/Makefile
 create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
 create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
 create mode 100644 drivers/simpleallocator/simple-allocator.c
 create mode 100644 include/uapi/linux/simple-allocator.h

-- 
1.9.1

[toc] | [next] | [standalone]

#1563724 — [RFC simple allocator v1 2/2] add CMA simple allocator module

This patch add simple allocator for CMA regions

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
 drivers/simpleallocator/Kconfig                |   7 +
 drivers/simpleallocator/Makefile               |   1 +
 drivers/simpleallocator/simple-allocator-cma.c | 187 +++++++++++++++++++++++++
 3 files changed, 195 insertions(+)
 create mode 100644 drivers/simpleallocator/simple-allocator-cma.c

diff --git a/drivers/simpleallocator/Kconfig b/drivers/simpleallocator/Kconfig
index c6fc2e3..788fb0b 100644
--- a/drivers/simpleallocator/Kconfig
+++ b/drivers/simpleallocator/Kconfig
@@ -7,4 +7,11 @@ config SIMPLE_ALLOCATOR
 	   The Simple Allocator Framework adds an API to allocate and share
 	   memory in userland.
 
+config SIMPLE_ALLOCATOR_CMA
+	tristate "Simple Allocator CMA"
+	select SIMPLE_ALLOCATOR
+	depends on DMA_CMA
+	---help---
+	   Select this option to enable Simple Allocator on CMA area.
+
 endmenu
diff --git a/drivers/simpleallocator/Makefile b/drivers/simpleallocator/Makefile
index e27c6ad..4e11611 100644
--- a/drivers/simpleallocator/Makefile
+++ b/drivers/simpleallocator/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_SIMPLE_ALLOCATOR) += simple-allocator.o
+obj-$(CONFIG_SIMPLE_ALLOCATOR_CMA) += simple-allocator-cma.o
diff --git a/drivers/simpleallocator/simple-allocator-cma.c b/drivers/simpleallocator/simple-allocator-cma.c
new file mode 100644
index 0000000..b240913
--- /dev/null
+++ b/drivers/simpleallocator/simple-allocator-cma.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (C) Linaro 2017
+ *
+ * Author: Benjamin Gaignard <benjamin.gaignard@linaro.org>
+ *
+ * License terms:  GNU General Public License (GPL)
+ */
+
+#include <linux/cma.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include "simple-allocator-priv.h"
+#include "../mm/cma.h"
+
+struct sa_cma_device {
+	struct sa_device parent;
+	struct cma *cma;
+};
+
+struct sa_cma_buffer_info {
+	void *vaddr;
+	size_t count;
+	size_t size;
+	struct page *pages;
+	struct sa_cma_device *sa_cma;
+};
+
+static struct sa_cma_device *sa_cma[MAX_CMA_AREAS];
+
+static inline struct sa_cma_device *to_sa_cma(struct sa_device *sadev)
+{
+	return container_of(sadev, struct sa_cma_device, parent);
+}
+
+static struct sg_table *sa_cma_map_dma_buf(struct dma_buf_attachment *attach,
+					   enum dma_data_direction direction)
+{
+	struct dma_buf *dmabuf = attach->dmabuf;
+	struct sa_cma_buffer_info *info = dmabuf->priv;
+	struct sg_table *sgt;
+	int ret;
+
+	ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
+	if (unlikely(ret))
+		return NULL;
+
+	sg_set_page(sgt->sgl, info->pages, PAGE_ALIGN(info->size), 0);
+	sg_dma_address(sgt->sgl) = (dma_addr_t) page_address(info->pages);
+	sg_dma_len(sgt->sgl) = PAGE_ALIGN(info->size);
+
+	return sgt;
+}
+
+static void sa_cma_unmap_dma_buf(struct dma_buf_attachment *attach,
+				 struct sg_table *sgt,
+				 enum dma_data_direction dir)
+{
+	kfree(sgt);
+}
+
+static int sa_cma_mmap_dma_buf(struct dma_buf *dmabuf,
+			       struct vm_area_struct *vma)
+{
+	struct sa_cma_buffer_info *info = dmabuf->priv;
+	unsigned long user_count = vma_pages(vma);
+	unsigned long count = info->count;
+	unsigned long pfn = page_to_pfn(info->pages);
+	unsigned long off = vma->vm_pgoff;
+	int ret = -ENXIO;
+
+	if (off < count && user_count <= (count - off)) {
+		ret = remap_pfn_range(vma, vma->vm_start,
+				      pfn + off,
+				      user_count << PAGE_SHIFT,
+				      vma->vm_page_prot);
+	}
+
+	return ret;
+}
+
+static void sa_cma_release_dma_buf(struct dma_buf *dmabuf)
+{
+	struct sa_cma_buffer_info *info = dmabuf->priv;
+
+	cma_release(info->sa_cma->cma, info->pages, info->count);
+
+	kfree(info);
+}
+
+static void *sa_cma_kmap_dma_buf(struct dma_buf *dmabuf, unsigned long offset)
+{
+	struct sa_cma_buffer_info *info = dmabuf->priv;
+
+	return page_address(info->pages) + offset;
+}
+
+static struct dma_buf_ops sa_dma_buf_ops = {
+	.map_dma_buf = sa_cma_map_dma_buf,
+	.unmap_dma_buf = sa_cma_unmap_dma_buf,
+	.mmap = sa_cma_mmap_dma_buf,
+	.release = sa_cma_release_dma_buf,
+	.kmap_atomic = sa_cma_kmap_dma_buf,
+	.kmap = sa_cma_kmap_dma_buf,
+};
+
+static struct dma_buf *sa_cma_allocate(struct sa_device *sadev,
+				       u64 length, u32 flags)
+{
+	DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+	struct sa_cma_buffer_info *info;
+	struct dma_buf *dmabuf;
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info)
+		return NULL;
+
+	info->count = round_up(length, PAGE_SIZE);
+	info->size = length;
+	info->sa_cma = to_sa_cma(sadev);
+
+	info->pages = cma_alloc(info->sa_cma->cma, info->count, 0);
+
+	if (!info->pages)
+		goto cleanup;
+
+	exp_info.ops = &sa_dma_buf_ops;
+	exp_info.size = info->size;
+	exp_info.flags = flags;
+	exp_info.priv = info;
+
+	dmabuf = dma_buf_export(&exp_info);
+	if (IS_ERR(dmabuf))
+		goto export_failed;
+
+	return dmabuf;
+
+export_failed:
+	cma_release(info->sa_cma->cma, info->pages, info->count);
+cleanup:
+	kfree(info);
+	return NULL;
+}
+
+struct sa_cma_device *simple_allocator_register_cma(struct cma *cma)
+{
+	struct sa_cma_device *sa_cma;
+	int ret;
+
+	sa_cma = kzalloc(sizeof(*sa_cma), GFP_KERNEL);
+	if (!sa_cma)
+		return NULL;
+
+	sa_cma->cma = cma;
+	sa_cma->parent.owner = THIS_MODULE;
+	sa_cma->parent.name = "cma";
+	sa_cma->parent.allocate = sa_cma_allocate;
+
+	ret = simple_allocator_register(&sa_cma->parent);
+	if (ret) {
+		kfree(sa_cma);
+		return NULL;
+	}
+
+	return sa_cma;
+}
+
+static int __init sa_cma_init(void)
+{
+	int i;
+
+	for (i = 0; i < cma_area_count; i++)
+		sa_cma[i] = simple_allocator_register_cma(&cma_areas[i]);
+
+	return 0;
+}
+
+static void __exit sa_cma_exit(void)
+{
+	int i;
+
+	for (i = 0; i < cma_area_count; i++)
+		simple_allocator_unregister(&sa_cma[i]->parent);
+}
+
+module_init(sa_cma_init);
+module_exit(sa_cma_exit);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1564763

On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:
> The goal of this RFC is to understand if a common ioctl for specific memory
> regions allocations is needed/welcome.
> 
> Obviously it will not replace allocation done in linux kernel frameworks like
> v4l2, drm/kms or others, but offer an alternative when you don't want/need to
> use them for buffer allocation.
> To keep a compatibility with what already exist allocated buffers are exported
> in userland as dmabuf file descriptor (like ION is doing).
> 
> "Unix Device Memory Allocator" project [1] wants to create a userland library
> which may allow to select, depending of the devices constraint, the best
> back-end for allocation. With this RFC I would to propose to have common ioctl
> for a maximum of allocators to avoid to duplicated back-ends for this library.
> 
> One of the issues that lead me to propose this RFC it is that since the beginning
> it is a problem to allocate contiguous memory (CMA) without using v4l2 or
> drm/kms so the first allocator available in this RFC use CMA memory.
> 
> An other question is: do we have others memory regions that could be interested
> by this new framework ? I have in mind that some title memory regions could use
> it or replace ION heaps (system, carveout, etc...).
> Maybe it only solve CMA allocation issue, in this case there is no need to create
> a new framework but only a dedicated ioctl.
> 
> Maybe the first thing to do is to change the name and the location of this 
> module, suggestions are welcome.
> 
> I have testing this code with the following program:

I'm still maintaining that we should just destage ION (with the todo items
fixed), since that is already an uabi to do this (afaiui at least), and
it's used on a few devices ... Please chat with Laura Abott.
-Daniel

> 
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/ioctl.h>
> #include <sys/mman.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> 
> #include "simple-allocator.h"
> 
> #define LENGTH 1024*16
> 
> void main (void)
> {
> 	struct simple_allocate_data data;
> 	int fd = open("/dev/cma0", O_RDWR, 0);
> 	int ret;
> 	void *mem;
> 
> 	if (fd < 0) {
> 		printf("Can't open /dev/cma0\n");
> 		return;
> 	}
> 
> 	memset(&data, 0, sizeof(data));
> 
> 	data.length = LENGTH;
> 	data.flags = O_RDWR | O_CLOEXEC;
> 
> 	ret = ioctl(fd, SA_IOC_ALLOC, &data);
> 	if (ret) {
> 		printf("Buffer allocation failed\n");
> 		goto end;
> 	}
> 
> 	mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> 	if (mem == MAP_FAILED) {
> 		printf("mmap failed\n");
> 	}
> 
> 	memset(mem, 0xFF, LENGTH);
> 	munmap(mem, LENGTH);
> 
> 	printf("test simple allocator CMA OK\n");
> end:
> 	close(fd);
> }
> 
> [1] https://github.com/cubanismo/allocator
> 
> Benjamin Gaignard (2):
>   Create Simple Allocator module
>   add CMA simple allocator module
> 
>  Documentation/simple-allocator.txt              |  81 ++++++++++
>  drivers/Kconfig                                 |   2 +
>  drivers/Makefile                                |   1 +
>  drivers/simpleallocator/Kconfig                 |  17 +++
>  drivers/simpleallocator/Makefile                |   2 +
>  drivers/simpleallocator/simple-allocator-cma.c  | 187 ++++++++++++++++++++++++
>  drivers/simpleallocator/simple-allocator-priv.h |  33 +++++
>  drivers/simpleallocator/simple-allocator.c      | 180 +++++++++++++++++++++++
>  include/uapi/linux/simple-allocator.h           |  35 +++++
>  9 files changed, 538 insertions(+)
>  create mode 100644 Documentation/simple-allocator.txt
>  create mode 100644 drivers/simpleallocator/Kconfig
>  create mode 100644 drivers/simpleallocator/Makefile
>  create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>  create mode 100644 include/uapi/linux/simple-allocator.h
> 
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1566398

On 01/23/2017 09:35 AM, Daniel Vetter wrote:
> On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:
>> The goal of this RFC is to understand if a common ioctl for specific memory
>> regions allocations is needed/welcome.
>>
>> Obviously it will not replace allocation done in linux kernel frameworks like
>> v4l2, drm/kms or others, but offer an alternative when you don't want/need to
>> use them for buffer allocation.
>> To keep a compatibility with what already exist allocated buffers are exported
>> in userland as dmabuf file descriptor (like ION is doing).
>>
>> "Unix Device Memory Allocator" project [1] wants to create a userland library
>> which may allow to select, depending of the devices constraint, the best
>> back-end for allocation. With this RFC I would to propose to have common ioctl
>> for a maximum of allocators to avoid to duplicated back-ends for this library.
>>
>> One of the issues that lead me to propose this RFC it is that since the beginning
>> it is a problem to allocate contiguous memory (CMA) without using v4l2 or
>> drm/kms so the first allocator available in this RFC use CMA memory.
>>
>> An other question is: do we have others memory regions that could be interested
>> by this new framework ? I have in mind that some title memory regions could use
>> it or replace ION heaps (system, carveout, etc...).
>> Maybe it only solve CMA allocation issue, in this case there is no need to create
>> a new framework but only a dedicated ioctl.
>>
>> Maybe the first thing to do is to change the name and the location of this
>> module, suggestions are welcome.
>>
>> I have testing this code with the following program:
>
> I'm still maintaining that we should just destage ION (with the todo items
> fixed), since that is already an uabi to do this (afaiui at least), and
> it's used on a few devices ... Please chat with Laura Abott.
> -Daniel
>

(I thought I sent this before but apparently it didn't go through.
Apologies if this ends up as a repeat for anyone)

I've been reviewing this as well. Even if Ion is used on a number of
devices, the model is still a bit clunky. I was hoping to see if it
could be re-written from scratch in a framework like this and then
either add a shim layer or just coax all devices out there to actually
convert to the new framework.

I supposed another option is to destage as you suggested and work on
an improved version in parallel.

Thanks,
Laura

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web