Date: Fri, 3 Dec 1999 07:13:46 +1100 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: eischen@vigrid.com, dcs@newsguy.com Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <99Dec3.070619est.40333@border.alcanet.com.au> In-Reply-To: <3846ADA5.72017F25@vigrid.com> References: <19991127223909.22A511FCF@io.yi.org> <3846A720.2BA461A6@newsguy.com> <3846ADA5.72017F25@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1999-Dec-03 04:34:29 +1100, Daniel M. Eischen wrote:
>"Daniel C. Sobral" wrote:
>> Mmmm... I though gettimeofday() was a very slow system call... I'll
>> have to check that.
...
>Not to say that clock_gettime is any better,
On my PII-266, clock_gettime(CLOCK_REALTIME) takes 2.48usec and
gettimeofday() takes 2.42usec - slightly better. Interestingly, in
both cases about 30% of the time is charged as user rather than system
- which suggests that either the kernel->user return is quite slow[*],
or something odd is going on.
I wouldn't consider either particularly slow (unless you count the
clock cycles taken - around 650).
Peter
[*] Since the kernel entry and kernel exit are non-interruptable, any
profiling interrupt will be delayed until the instruction is
complete. Thus the kernel entry will be charged to the system,
and the exit will be charged to the user.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Dec3.070619est.40333>