[Linaro-mm-sig] Memory Management Discussion
Tom.Cooksey at arm.com
Thu Apr 21 10:58:59 UTC 2011
Please excuse my naivety, but won't SurfaceFlinger start hitting the same "I need more than 1024 file descriptors" issue as the X-server at some point? I guess most current Android devices don't have 100s of applications running at the same time, but it doesn't seem completely inconceivable they might in the future? I also seem to remember reading something about binder also using file descriptors to pass buffers between processes, so it's potentially not just graphics buffers?
On the same point, can't the X-server/SurfaceFlinger run as a user which has the file descriptor ulimit raised above 1024? Or is the 1024 a more fundamental limit/implementation constraint?
From: linaro-mm-sig-bounces at lists.linaro.org [mailto:linaro-mm-sig-bounces at lists.linaro.org] On Behalf Of Rebecca Schultz Zavin
Sent: 20 April 2011 22:32
To: Dave Airlie
Cc: linaro-mm-sig at lists.linaro.org; Arnd Bergmann
Subject: Re: [Linaro-mm-sig] Memory Management Discussion
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:
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.
On Wed, Apr 20, 2011 at 1:48 PM, Dave Airlie <airlied at gmail.com<mailto: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.
Linaro-mm-sig mailing list
Linaro-mm-sig at lists.linaro.org<mailto:Linaro-mm-sig at lists.linaro.org>
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linaro-mm-sig