Date: Fri, 14 Oct 2005 10:10:04 +0100 From: Brian Candler <B.Candler@pobox.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Max Laier <max@love2party.net>, freebsd-current@freebsd.org, Eric Anderson <anderson@centtech.com> Subject: Re: ufsstat - testers / feedback wanted! Message-ID: <20051014091004.GC18513@uk.tiscali.com> In-Reply-To: <20051013181026.GB27418@odin.ac.hmc.edu> References: <434E46C0.7060903@centtech.com> <200510131412.23525.max@love2party.net> <20051013181026.GB27418@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 13, 2005 at 11:10:26AM -0700, Brooks Davis wrote:
> > I don't think you can measure one single interger (or 64bit) increase in face
> > of a operation that has to access backing store. Even if there is a
> > performance hit, you don't have to build your kernel with the option enabled.
>
> The one thing I'd be worried about here is that 64bit updates are
> expensive on 32bit machines if you want them to be atomic. Relative to
> backing store they probably still don't matter, but the might be
> noticable.
I'd be grateful if you could clarify that point for me. Are you saying that
if I write
long long foo;
...
foo++;
then the C compiler generates code for 'foo++' which is not thread-safe?
(And therefore I would have to protect it with a mutex or critical section)
Or are you saying that the C compiler inserts its own code around foo++ to
turn it into a critical section, and therefore runs less efficiently than
you'd expect?
Regards,
Brian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051014091004.GC18513>