On Thu, Apr 21, 2011 at 3:58 AM, Tom Cooksey Tom.Cooksey@arm.com wrote:
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?
The binder uses it's own method for ipc between processes. Sometimes it shares memory that way between processes.
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?
I don't think that would be a problem. Also I don't think the Android stack uses select for anything.
Rebecca
Cheers,
Tom
*From:* linaro-mm-sig-bounces@lists.linaro.org [mailto: linaro-mm-sig-bounces@lists.linaro.org] *On Behalf Of *Rebecca Schultz Zavin *Sent:* 20 April 2011 22:32 *To:* Dave Airlie *Cc:* linaro-mm-sig@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:
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@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
-- 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.