Date: Sun, 17 Feb 2002 23:06:24 -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: <3C70A7F0.C409B43F@mindspring.com> References: <20020218144148.F4583-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I guess you want me to implement it again, outside the context of the code I implemented for ClickArray, and donate it back to the project? The only dependency is that the context is not updated during the copy operation itself, which can be guaranteed by a single "generation" counter save before/test after around the copy (trivial). In actual practice, I've never seen this happen in the time it took the inline function version of the expanded gettimeofday() to run, even under heavy load. I think that's because everything fits in cache, though I can't guarantee that missing two time slices has ever happened in that application (in any case, it's protected). > > 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. Not really. The time stamps are spread over a fairly high latency path of client connection, request complete, connection to back end, request sent, response received, response sent, disconnect. While concurrent requests may end up with the same stamp, individual client timings are pretty accurate -- at least as accurate as calling the kernel kettimeofday() instead, within a very small variance (~.1ms, measured). > > Crossing protection domains for read-only data which is > > frequently accessed is a really, really bad idea. > > Does it really matter for logging? If all you were doing was logging, no, but since the logging is indicative of doing work, yes. 8-) 8-). A significant amout of the system call overhead in the processing of a kevent based program is in the logging. One approach we considered was to add a timestamp to the kevents themselves, and log using that, instead, but it turns out that the logging frequency was lower than the even frequency by enough of a margin that the expense of doing that was too high. -- 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?3C70A7F0.C409B43F>