Re: [RFC simple allocator v1 0/2] Simple allocator
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC simple allocator v1 0/2] Simple allocator
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 > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #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(, 0, sizeof(data)); > > data.length = LENGTH; > data.flags = O_RDWR | O_CLOEXEC; > > ret = ioctl(fd, SA_IOC_ALLOC, ); > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 #include #include #include #include #include #include #include #include #include #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(, 0, sizeof(data)); data.length = LENGTH; data.flags = O_RDWR | O_CLOEXEC; ret = ioctl(fd, SA_IOC_ALLOC, ); 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html