Re: Evaluation of High Precision Event Timer Driver for userland timer facility

In message <4641B1C2.70909_at_ybb.ne.jp>, Takeharu KATO writes:
>Hi,
>
>I wrote a patch to add following features into acpi_hpet timer driver
>(The patch is posted as PR kern/112544).

I have briefly scanned your patch and have some comments.

Basing this facility on the HPET almost guarantees that we cannot
use it in FreeBSD, because the HPET is not available on more than
a couple of our architectures.

The underlying timecounters have datastructures that can be used
to implement the mmap(2) access to user-space, but access to the
necessary hardware is not readily available, as that more often
than not, requires kernel privileges.

Without userland access to the timekeeping hardware, it is difficult
to avoid the system call overhead and once in the kernel anyway
it is doubtful that splitting the code between userland and
kernel really gives much of a payoff.

I am aware that Linux has a userland timestamping facility, but
I am also aware of its numerous shortcomings.

>feature-1) Global time stamp for SMP machines.
>   This driver provides a common time-base on N-Way MP system via
>   mmap system call.
>   It is not affected by clock freq. drifts.

This is an incredibly tall claim that has no backing in reality.

>feature-2) Periodic timer facility
>    This driver provides periodic timer facility for userland applications to
>   use for appication specific process scheduling.

This should under no circumstances be committed without an architecture
and hardware independent API.  We already have [gs]etitimer() for this
purpose.

If we want to do something like this, we want to do it right, and
that means giving the timeout mechanism in the kernel a good
workout.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.