Date: Fri, 28 Oct 2005 21:25:03 +0800 From: David Xu <davidxu@freebsd.org> To: ticso@cicely.de Cc: Pertti Kosunen <pertti.kosunen@pp.nic.fi>, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@freebsd.org, "Yuriy N. Shkandybin" <jura@networks.ru> Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <436226AF.10109@freebsd.org> In-Reply-To: <20051028125828.GE66456@cicely12.cicely.de> References: <31129.1130495688@critter.freebsd.dk> <436200BE.70604@freebsd.org> <20051028125828.GE66456@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote: >On Fri, Oct 28, 2005 at 06:43:10PM +0800, David Xu wrote: > > >>Poul-Henning Kamp wrote: >> >> >>>In message <4361FDBE.7000500@freebsd.org>, David Xu writes: >>> >>> >>>the correct way to optimize this would be to add a time(2) systemcall >>>which returns the value of the kernel global time_second. >>> >>> >>> >>Can we make a page in kernel address space which is readable my user >>code? put the variable in the page, I know read an integer is atomic-op, >>needn't lock, so syscall is not needed. >> >> > >Don't whink it is importent for 1s intervalls, but atomic != coherent. > > > That's just an idea. :-) As robert said, add a lower resolution CLOCK_ type may work well. Another thing I just though of, if reading timercounter is so slow, won't gettimeofday hardly block cpu too many cycles ? the cpu is just stucked there by a slow clock in hardware signals.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?436226AF.10109>