Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?)

From: David Xu <davidxu_at_freebsd.org>
Date: Mon, 31 Oct 2005 18:48:39 +0800
Poul-Henning Kamp wrote:
> In message <4365EF7B.1020706_at_freebsd.org>, David Xu writes:
>>Can we change gettimeofday and clock_gettime to lower resolution now?
> 
> 
> I can live with gettimeofday(2) and time(3) being degraded.
> 
> I am going to insist that clock_gettime(CLOCK_REALTIME, CLOCK_UPTIME)
> remain precise.
> 

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.

> 
>>I think 1000hz/s is enough for most applications, since a thread can
>>never sleep shorter than a tick for years.
> 
> 
> (Famous last words!)
> 
> Time is not just a matter of sleeping.
> 
> 
>>We can introduce
>>hrtime_t clock_gethrtime(clockid_t clock) to get hi-resolution time
>>as the one seen in RTLinux, or gethrtime() as seen in Solaris (Daniel
>>Eischen said?)
> 
> 
> You know ? 
> 
> This is just a great example of why people feel the autocrap tools
> is the way to write portable code :-(
> 
> The open group specifically allow clock_gettime() to implement
> more timescales, so what did those fools go and invent even more
> library functions for ?
> 
> Poul-Henning
> 

You can introduce other CLOCK_..., but auto tools won't detect them too,
this means nobody will use them except us, probably worse then
gethrtime. :-(
Received on Mon Oct 31 2005 - 09:48:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC