Messages in this thread | | | Date | Thu, 15 Sep 2005 15:05:18 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH] reorder struct files_struct |
| |
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/
| |