Date: Mon, 31 Oct 2005 10:53:45 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: Alexander Leidinger <Alexander@Leidinger.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-current@freebsd.org Subject: Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?) Message-ID: <20051031104949.D11619@fledge.watson.org> In-Reply-To: <4365F687.3070105@freebsd.org> References: <81213.1130754398@critter.freebsd.dk> <4365F687.3070105@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Oct 2005, David Xu wrote: > In thread program, we have to use clock_gettime, for example a thread > wants to wait for condition variable for two seconds, it has to: > > struct timespec ts; > > clock_gettime(CLOCK_REALTIME, &ts); > ts.tv_sec += 2; > pthread_cond_wait(&cond, &mtx); > > problem is who really cares time precise? how many people are really > handling realtime critical tasks? this is really an unpleasant side > effect that a simple syscall can stall cpu. The questions are: how good is good enough? And for what? The problem here is that while pthread_cond_wait() can afford to accept low resolution, the same clock retrieval interface is also used for things like scientific measurement. So it sounds like the real mistake was the specification for the thread API: while timespec is the New Way for time-related interfaces, this approach has coalesced precision time measurement and "how long to sleep for" time measurement. Moving to HZ incrementing of the clock probably exceeds the quality reduction that makes sense for clock_gettime(), but moving to a roughly sync'd TSC clock (such as the Linux approach) probably doesn't. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051031104949.D11619>