[Linaro-mm-sig] Memory Management Discussion

Rebecca Schultz Zavin rebecca at android.com
Wed Apr 20 21:32:07 UTC 2011


I've been lurking on this thread all day since I've been underwater on
something else but I want to give some perspective on both things that we've
done on Android in the past and where we are going in the future that's
relevant to the fd's vs. "cookies" discussion here.  I've owned the "memory
manager" component on pretty much every android program the android team has
been involved with directly, qualcomm's pmem was written by me, nvidia's
nvmap was heavily modified, many of ti's things flowed through my fingers
etc.  As many of you know, we're also working on our own new solution -- yes
I know we don't need one more from google, but really you already have
several from google, we're trying to replace them with one that solves all
the problems the others do.

As Arnd has pointed out, filedescriptors give us for free a lot of things we
desperately need, especially lifetime management.  This is probably the
single biggest source of bugs around multimedia and graphics.  Moving
forward we are going to make it a requirement that buffers must exist in
file descriptors while they are in userspace, so they automatically get
reference counted correctly when they are passed between processes.  Any
solution that doesn't do that will not be compatible with Anrdoid's next
generation gralloc api.

That being said, I think all the detractors of file descriptors can be
easily worked around.  My proposal is to only "promote" buffers into file
descriptors while they are being passed or mmaped.  This way, we can easily
manage the number of fds required in the system.  If you want to see how
that might work, take a look at my first stab at an implementation for a new
memory manager here:

https://review.source.android.com/#change,22239

I was waiting to post that until I had time to put together some cogent
documentation for it, but it sounds like it's time has come.  Comments are
welcome there or by email.  Keep in mind it's intended to implement the
basic api without the machinery to manage the related hardware and it's
still a work in progress.

Rebecca



On Wed, Apr 20, 2011 at 1:48 PM, Dave Airlie <airlied at gmail.com> wrote:

> > * Efficient lookup in system calls
> > * Established ways to pass them around
> > * Easy to mmap() -- if you want to map anything into user space, you
> >  need a file descriptor anyway
>
> This isn't a great boon as we've seen with GEM and TTM.
>
> The problem for GEM was we used shmem to back the fds, so the mmap
> was a cached mapping, now when we had alternate mapping available
> such as via the GTT we had to go and add code to mmap via that drm file
> descriptor. Though probably could have gotten around that by changing the
> mmap backing away from shmem.
>
> Dave.
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-mm-sig/attachments/20110420/4bb88509/attachment.html>


More information about the Linaro-mm-sig mailing list