Re: [PATCH] reorder struct files_struct

[Dipankar Sarma <dipankar@in.ibm.com>]

On Thu, Sep 15, 2005 at 08:17:40AM +0200, Eric Dumazet wrote:
> Dipankar Sarma a écrit :
> >On Thu, Sep 15, 2005 at 01:19:47AM +0200, Eric Dumazet wrote:
> >
> >Those fdsets would share a cache line with fdt, fdtable which would
> >be invalidated on open/close. So, what is the point in moving
> >file_lock ?
> >
> 
> The point is that we gain nothing in this case for 32 bits platforms, but 
> we gain something on 64 bits platform. And for apps using more than 

I am not sure about that. IIRC, x86_64 has a 128-byte L1 cacheline.
So, count, fdt, fdtab, close_on_exec_init and open_fds_init would
all fit into one cache line. And close_on_exec_init will get updated
on open(). Also, most apps will not likely have more than the
default # of fds, it might not be a good idea to optimize for
that case.


> struct files_struct {
> 
> /* mostly read */
> 	atomic_t count; /* offset 0x00 */
> 	struct fdtable *fdt; /* offset 0x04 (0x08 on 64 bits) */
> 	struct fdtable fdtab; /* offset 0x08 (0x10 on 64 bits)*/
> 
> /* read/written for apps using small number of files */
> 	fd_set close_on_exec_init; /* offset 0x30 (0x58 on 64 bits) */
> 	fd_set open_fds_init; /* offset 0x34 (0x60 on 64 bits) */
> 	struct file * fd_array[NR_OPEN_DEFAULT]; /* offset 0x38 (0x68 on 64 
> 	bits */
> 	spinlock_t file_lock; /* 0xB8 (0x268 on 64 bits) */
> 	}; /* size = 0xBC (0x270 on 64 bits) */
> 
> Moving next_fd from 'struct fdtable' to 'struct files_struct' is also a win 
> for 64bits platforms since sizeof(struct fdtable) become 64 : a nice power 
> of two, so 64 bytes are allocated instead of 128.

Can you benchmark this on a higher end SMP/NUMA system ?

Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/