[Linaro-mm-sig] Memory Management Discussion

[Jordan Crouse]

On 04/20/2011 06:23 AM, Tom Cooksey wrote:
>
>
>> -----Original Message-----
>> From: linaro-mm-sig-bounces at lists.linaro.org [mailto:linaro-mm-sig-
>> bounces at lists.linaro.org] On Behalf Of Daniel Vetter
>> Sent: 20 April 2011 07:56
>> To: Arnd Bergmann
>> Cc: linaro-mm-sig at lists.linaro.org
>> Subject: Re: [Linaro-mm-sig] Memory Management Discussion
>>
>> On Wed, Apr 20, 2011 at 8:25 AM, Arnd Bergmann<arnd at arndb.de>  wrote:
>>> On Wednesday 20 April 2011 03:52:53 Clark, Rob wrote:
>>>>  From DRI perspective.. I guess the global buffer name is restricted
>>>> to a 4 byte integer, unless you change the DRI proto..
>>>
>>> I still like the idea of using file handles to pass the buffers
>>> between kernel subsystems. Maybe there could be an ioctl to encapsulate
>>> a buffer from DRI in a file so we can give it to another subsystem,
>>> and/or an ioctl to register a buffer from a file handle with DRI.
>>
>> That's been the original design of gem, i.e. using fd handles (and
>> perhaps even passing them around in unix domain sockets). There's one
>> small problem with that approach: You're quickly running out of fds
>> with the linux default limit of 1024. Hence the roll-your-own approach.
>
> There's a big difference between GEM and what we're trying to do. GEM is
> designed to manage _all_ buffers used by the graphics hardware. What I
> believe we're trying to do is only provide a manager which allows buffers
> to be shared between devices. Of all the buffers and textures a GPU needs
> to access, only a tiny fraction of them need to be shared between devices
> and userspace processes. How large that fraction is I don't know, it might
> still be approaching the 1024 limit, but I doubt it...

I don't think that is an accurate characterization.

Sharing *is* important, but at least this vendor is looking for a way to allocate all
multimedia related buffers, shared or not.  Even if you never shared a single buffer
between processes everything else we've put on the table re memory management is still a concern:
cache policy, contiguous vs paged, IOMMU, etc, etc.  I'm in the market for one memory
manager to rule them all.

Jordan