Re: [PATCH] reorder struct files_struct

[Andrew Morton <akpm@osdl.org>]

Dipankar Sarma <dipankar@in.ibm.com> wrote:
>
> > --- linux-2.6.14-rc1/include/linux/file.h	2005-09-13 05:12:09.000000000 +0200
> > +++ linux-2.6.14-rc1-ed/include/linux/file.h	2005-09-15 01:09:13.000000000 +0200
> > @@ -34,12 +34,12 @@
> >   */
> >  struct files_struct {
> >          atomic_t count;
> > -        spinlock_t file_lock;     /* Protects all the below members.  Nests inside tsk->alloc_lock */
> >  	struct fdtable *fdt;
> >  	struct fdtable fdtab;
> >          fd_set close_on_exec_init;
> >          fd_set open_fds_init;
> >          struct file * fd_array[NR_OPEN_DEFAULT];
> > +	spinlock_t file_lock;     /* Protects concurrent writers.  Nests inside tsk->alloc_lock */
> >  };
> >  
> >  #define files_fdtable(files) (rcu_dereference((files)->fdt))
> 
> For most apps without too many open fds, the embedded fd_sets
> are going to be used. Wouldn't that mean that open()/close() will
> invalidate the cache line containing fdt, fdtab by updating
> the fd_sets ? If so, you optimization really doesn't help.

Guys, this is benchmarkable.  fget() is astonishingly high in some
profiles - it's worth investigating.