lkml.org 
[lkml]   [2009]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/2] fs: mnt_want_write speedup
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.


\
 
 \ /
  Last update: 2009-03-10 16:07    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site