From owner-freebsd-current@FreeBSD.ORG Wed May 23 16:19:01 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBB4B16A400 for ; Wed, 23 May 2007 16:19:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A98D513C4B8 for ; Wed, 23 May 2007 16:19:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 656AB173B4; Wed, 23 May 2007 16:19:00 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l4NGJLJc006015; Wed, 23 May 2007 16:19:22 GMT (envelope-from phk@critter.freebsd.dk) To: Takeharu KATO From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 May 2007 20:34:26 +0900." <4641B1C2.70909@ybb.ne.jp> Date: Wed, 23 May 2007 16:19:21 +0000 Message-ID: <6014.1179937161@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Evaluation of High Precision Event Timer Driver for userland timer facility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 16:19:02 -0000 In message <4641B1C2.70909@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@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.