Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Apr 2007 11:39:24 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>
Cc:        Tim Kientzle <kientzle@freebsd.org>, David G Lawrence <dg@dglawrence.com>, "Jesper B. Rosenkilde" <jbr@humppa.dk>, current@freebsd.org
Subject:   Re: Suggestions on Avoiding syscall Overhead
Message-ID:  <20070428113752.A28395@fledge.watson.org>
In-Reply-To: <86veflholn.fsf@dwp.des.no>
References:  <f126fae00704221639l68095de1ye7ce9ba3d921bf20@mail.gmail.com> <20070423113400.GC28587@gw.humppa.dk> <462CD251.9060105@freebsd.org> <20070423161711.GV39474@elvis.mu.org> <462D821F.6030707@freebsd.org> <20070424042102.GI38475@tnn.dglawrence.com> <86veflholn.fsf@dwp.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1788945292-1177756764=:28395
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE


On Tue, 24 Apr 2007, Dag-Erling Sm=F8rgrav wrote:

> David G Lawrence <dg@dglawrence.com> writes:
>> gettimeofday(2) returns microsecond precision, so I don't see how this=
=20
>> could be made accelerated via a mapped global page. time(3) [which is=20
>> currently a wrapper for gettimeofday(2)], on the other had, could be put=
=20
>> into such a page since it only updates once a second.
>
> gettimeofday(2) returns a value in microseconds, but this does not=20
> necessarily mean that it has microsecond precision.  Updating it once per=
=20
> scheduler tick or once per context switch (in userret(), for instance) is=
=20
> probably enough.

We have an overall issue with the cost vs prevision of time measurement in=
=20
FreeBSD.  We err on the side of precision; other systems err on the side of=
=20
cost.  I'm not sure that gettimeofday() is best optimized in the way you=20
describe, since if we're going to sacrifice precision, we could sacrifice a=
=20
lot less precision and still get massively better performance.

Robert N M Watson
Computer Laboratory
University of Cambridge
--0-1788945292-1177756764=:28395--



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