-----Original Message----- From: linaro-mm-sig-bounces@lists.linaro.org [mailto:linaro-mm-sig- bounces@lists.linaro.org] On Behalf Of Jesse Barnes Sent: 21 April 2011 16:00 To: Arnd Bergmann Cc: linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] Memory Management Discussion
On Thu, 21 Apr 2011 13:37:57 +0200 Arnd Bergmann arnd@arndb.de wrote:
On Thursday 21 April 2011, Tom Cooksey 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?
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?
There are two limits to consider here:
the ulimit you mentioned, this can be set by any process with CAP_SYS_RESOURCE, and gets inherited by its children.
The libc implementation specific FD_SET_SIZE, which limits the highest file descriptor number that can be passed into the select system call.
I believe in case of Android, neither of these is a serious problem. For 1, this means giving a high ulimit to the SurfaceFlinger, as you said. For 2, setting the libc FD_SET_SIZE higher is one option (as long as you don't require binary compatibility with old apps that dynamically link to libc), another option is to replace all remaining calls to select() in SurfaceFlinger with calls to epoll(), which is probably used already because it is more efficient.
In case of glibc, changing FD_SET_SIZE is not an option, and running the X server with a higher ulimit is also not desired (we want to move to running it from regular users instead of root), but there are probably ways to work around that.
Client apps also have to worry about the fd count, since depending on the app and object caching policy it's very easy to get over 1024 objects. But the solutions above may work for that case as well; I don't expect many apps rely on select(), and those that do can fairly easily be converted.
Though presumably not if you only have an fd for buffers you want to share with another process or device? I think the common case is you don't want to share a texture or command buffer or whatever with another process, so most of the objects don't need an fd?
Cheers,
Tom
-- 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.