Dipankar Sarma a écrit :
> On Thu, Sep 15, 2005 at 12:42:03AM +0200, Eric Dumazet wrote:
> 
>>Dipankar Sarma a écrit :

> Not just embedded fdtable, but also the embedded fdsets. I would expect
> count, fdt, fdtab and the fdsets to fit into one cache line in 
> some archs.
> 
> 
> 
>>But I wonder if 'next_fd' really has to be in 'struct fdtable', maybe it 
>>could be moved to 'struct files_struct' close to file_lock ?
> 
> 
> next_fd has to be in struct fdtable. It needs to be consistent
> with whichever fdtable a lock-free reader sees.
> 

I may be wrong, but I think a reader never look at next_fd.

next_fd is only used (read/written) by a 'writer', with file_lock hold,  in 
locate_fd(), copy_fdtable() and get_unused_fd(), __put_unused_fd()


> 
>>If yes, the whole embedded struct fdtable is readonly.
> 
> 
> But not close_on_exec_init or open_fds_init. We would update them
> on open/close.

Yes, sure, but those fields are not part of the embedded struct fdtable

> 
> Some benchmarking would be useful here.

This simple bench can be used, I got good results on a dual opteron machine. 
As Opterons have prety good NUMA links (Hypertransport), I suspect older 
hardware should obtain even better results.

$ gcc -O2 -o bench bench.c -lpthread
$ ./bench -t 2 -l 10   # run the bench with 2 threads for 10 seconds.
2 threads, 10 seconds, work_done=1721627

To run it with a small fdset (no more than 3 + (nbthreads) files opened)
$ ./bench -s -t 2 -l 10
2 threads, 10 seconds, work_done=1709716

Unfortunatly I cannot boot the dual opterons at the moment to try to move 
next_fd close to file_lock

Eric