TSC instead of ACPI: powerd doesn't work anymore (to be
expected?)
David Xu
davidxu at freebsd.org
Mon Oct 31 02:48:39 PST 2005
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. :-(
More information about the freebsd-current
mailing list