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


Groups > linux.kernel > #1566398

Re: [RFC simple allocator v1 0/2] Simple allocator

From Laura Abbott <labbott@redhat.com>
Newsgroups linux.kernel
Subject Re: [RFC simple allocator v1 0/2] Simple allocator
Date 2017-01-25 10:20 +0100
Message-ID <t3rUd-8k5-19@gated-at.bofh.it> (permalink)
References <t1Jsd-z6-7@gated-at.bofh.it> <t2Ikp-47r-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[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

csiph-web