Linus Torvalds a écrit :
> 
> On Thu, 15 Sep 2005, Benjamin LaHaise wrote:
> 
>>Alternatively, the kernel could track available file descriptors using a 
>>tree to efficiently insert freed slots into an ordered list of free 
>>regions (something similar to the avl tree used in vmas).  Is it worth 
>>doing?
> 
> 
> For file descriptors, even a few hundred is considered a _lot_ in almost 
> all settings. Yes, you can certainly have more, but it's unusual.
> 
> And we keep track of the fd reservations with a bitmap _and_ a "lowest
> possible" count. So we can check 32 fd's in one go (64 on modern setups),
> starting from the last one we allocated.
> 
> In other words, no. It's not worth doing anything more than we already do. 
> 
> I bet all the expense in this area tends under heavy load to be the
> cacheline bouncing of the updates. Keeping the lock close to the bitmap is 
> probably advantageous, since the bitmap tends to be looked at only when we 
> need to change them (and we hold the lock).

Absolutely :)

Here is the patch I use to :

- place modified bits (file_lock & next_fd) in a separate cache line, reducing 
cacheline bouncing for multi threaded apps.
- Reduce the size of struct (files_struct), using small embedded fd_sets 
matching fd_array[NR_OPEN_DEFAULT] (ie one long per 'fd_set' instead of 128 bytes)
- 10 % gain on a benchmark ran on a dual HT Xeon 2GHz, one thread per logical CPU.

Eric

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>