Date: Mon, 18 Feb 2002 14:52:51 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> 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: <20020218144148.F4583-100000@gamplex.bde.org> In-Reply-To: <3C70500B.31282873@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Feb 2002, Terry Lambert wrote: > Bruce Evans wrote: > > 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. That can't be used to implement gettimeofday(). It can only be used to implement the userland equivalants of get_micro[up]time() and get_nano[up]time(). I don't like using these even for stamping file times in seconds in the kernel (though they have more than enough precision for this), since they give times that are incoherent relative to other ways of determining the time. > 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. Apparently they don't actually look at the timestamps and notice that they (the timestamps) are often the same for different transactions because the timestamps have low resolution. You can fake the increment, but then you can fake the time too. > Crossing protection domains for read-only data which is > frequently accessed is a really, really bad idea. Does it really matter for logging? Bruce 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?20020218144148.F4583-100000>