cvs commit: src/sys/sys vnode.h

[Jeff Roberson]

On Wed, 23 Feb 2005, Poul-Henning Kamp wrote:

> In message <20050223014018.Y52537 at mail.chesapeake.net>, Jeff Roberson writes:
> >On Wed, 23 Feb 2005, Poul-Henning Kamp wrote:
> >
> >> In message <20050222180223.V52537 at mail.chesapeake.net>, Jeff Roberson writes:
> >> >On Tue, 22 Feb 2005, Poul-Henning Kamp wrote:
> >> >
> >> >> phk         2005-02-22 18:49:03 UTC
> >> >>
> >> >>   FreeBSD src repository
> >> >>
> >> >>   Modified files:
> >> >>     sys/sys              vnode.h
> >> >>   Log:
> >> >>   Group the fields in struct vnode by their function and stick comments
> >> >>   there to tell what the function is.
> >> >
> >> >They were sorted according to the lock that they used.  I still prefer
> >> >that, prehaps with sorting by use secondly.
> >>
> >> That doesn't make sense.  The comment says which lock they use so people
> >> can still see that, but appearantly people had big trouble seeing what
> >> fields belonged where.
> >
> >It was so that we minimize cache hits, and cause a minimum number of
> >synchronized writes when we release the mutex.
>
> It still doesn't make sense Jeff, they're still mostly ordered by
> lock if you look carefully.  A little shuffling inside the groups
> will make it even more so.
>
> And I want to see benchmarks before you claim any performance
> degradation because I ram benchmarks and was not even within one
> tenth of the standard deviation.

I didn't claim any performance degradation, because I'm sure you can't
measure any in world bench.  It is simply a habbit of mine that I feel is
sound as it has made measurable differences in other datastructures.
Mostly I'd prefer it if the mtx was near the fields it protected, although
it's still not likely to put them all in the same cache line due to other
alignment problems.

I really don't care though, we can leave it as it is.  I just wanted to
point out that there was some order before.

Cheers,
Jeff

>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>