On Tue, Mar 10, 2009 at 08:48:57AM -0600, Matthew Wilcox wrote: > On Tue, Mar 10, 2009 at 03:37:18PM +0100, Nick Piggin wrote: > > costly, unfortunately). It results in about 900 bytes smaller code too. It > > does increase the size of a vfsmount, however. > > Only on 64-bit SMP systems, and then only by four bytes. And, best of > all, you can fix that if you care. Look at this: > > /* --- cacheline 1 boundary (64 bytes) --- */ > struct list_head mnt_child; /* 64 16 */ > int mnt_flags; /* 80 4 */ > > /* XXX 4 bytes hole, try to pack */ > > const char * mnt_devname; /* 88 8 */ > struct list_head mnt_list; /* 96 16 */ > struct list_head mnt_expire; /* 112 16 */ > > So move mnt_flags to later in the struct (after the pointers), and move > > > +#ifdef CONFIG_SMP > > + int *mnt_writers; > > +#else > > + int mnt_writers; > > +#endif > > to be with the other pointers. Bonus points for putting it between > struct mnt_namespace * mnt_ns; /* 184 8 */ > and > int mnt_id; /* 192 4 */ > > so that it doesn't become a new 4-byte hole for those incredibly common > 64-bit uniprocessor builds. *cough*. Oh good point, although yes I was more worried about mnt_writers in the SMP case (yes I didn't state it very well). Basically I would be worried if huge machinges have huge numbers of mounts.... but I think a) if they did they would probably like the scalability improvements, b) the improvement on smaller systems is so significant that 100s of CPU systems will have to find a way to cut down memory if it really was a problem for them. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
