[Linaro-mm-sig] Memory Management Discussion

[Arnd Bergmann]

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:

1. the ulimit you mentioned, this can be set by any process with
   CAP_SYS_RESOURCE, and gets inherited by its children.

2. 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.

	Arnd