Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 May 2006 07:26:27 +0800
From:      David Xu <davidxu@freebsd.org>
To:        freebsd-performance@freebsd.org
Cc:        Greg 'groggy' Lehey <grog@freebsd.org>, Robert Watson <rwatson@freebsd.org>, performance@freebsd.org, current@freebsd.org, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
Message-ID:  <200605100726.28243.davidxu@freebsd.org>
In-Reply-To: <20060509182330.GB92714@xor.obsecurity.org>
References:  <20060506150622.C17611@fledge.watson.org> <20060509181302.GD3636@eucla.lemis.com> <20060509182330.GB92714@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 10 May 2006 02:23, Kris Kennaway wrote:
> There are at least several issues here:
>
> * Factor of >two difference in performance across the board (all
> loads) relative to Linux.  This may be general issues like
> gettimeofday() on Linux vs FreeBSD; clearly there is something *very
> big* to blame here.  Mysql does do *lots* of such calls, so the cost
> of them is surely a component in performance, the only question is if
> it's the main one.
>
My last recall is that gettimeofday is not a syscall on Linux, they called
it vgettimeofday, they also have a lower overhead syscall: vsyscall which
uses sysenter/sysexit when CPU supports, they do calculation in userland,
the page is exported by kernel which can be executed by userland.
at least I saw the idea on one serious hacker's blog, but now I can not find 
the URL.

> * When you get some of the locking out of the way (per this thread)
> FreeBSD has 44% better peak performance on Sven's test on amd64, but
> tails off by about 33% at higher loads compared to unpatched.  I see
> similar changes on 12-CPU E4500, but not as much performance gain (may
> be due to other reasons).  i.e. optimizing the locking allows a new,
> bigger bottleneck to suck on center stage.  This is the basis for my
> observation about libthr at high loads.  It is not the same as the
> above issue.
>
> Kris

Fixing one of big lock contentions is not enough, you have to fix them
all, it is easy to see that a second contention becomes a top one. :-)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605100726.28243.davidxu>