Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Feb 2002 16:51:23 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Matthew Dillon <dillon@apollo.backplane.com>, Julian Elischer <julian@elischer.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca
Subject:   Re: gettimeofday() and crhold()/crfree() (was Re:  gettimeofday()andcopyout(). Is copyout() MPSAFE on non-i386 archs? )
Message-ID:  <3C70500B.31282873@mindspring.com>
References:  <20020218112751.T3970-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> > If we want to do fancy timekeeping, I have/had a patch which put
> > the timecounters on a single page which a process could map (hacked
> > with a special device driver).  Provided that the process has acccess
> > to reading the timecounter (== not i8254) all the time-calculations
> > can be done in userland without any calls into the kernel.
> 
> I know the synchronization costs for this would be high.  They are too
> high even in the kernel, so we skip them for the get*time() family,
> at the cost of getting unsynchronised times.  This may be acceptable
> in some applications.  The read-only variable in kernel memory has
> similar synchronisation problems.  It corresponds fairly directly
> with the variable read by the get*time() family.

I *know* that it is a significant win to flip-flop the
timecounter context into a reflected user space page
on each and every clock interrupt.

The benefits to doing this for squid alone, which must
make about 5 gettimeofday() calls per transaction in
order to do "correct" logging (IMO, logging is eye candy,
though some idiots insist on billing based on post
processing log files), are more than significant, they
are a doubling of the transaction rate.

Crossing protection domains for read-only data which is
frequently accessed is a really, really bad idea.

-- Terry

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?3C70500B.31282873>