From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 15:28:15 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4121716A417 for ; Sun, 2 Dec 2007 15:28:15 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC1D13C4F4 for ; Sun, 2 Dec 2007 15:28:15 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id lB2FQxxh009376; Sun, 2 Dec 2007 07:26:59 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id lB2FQwfI009375; Sun, 2 Dec 2007 07:26:58 -0800 (PST) (envelope-from rizzo) Date: Sun, 2 Dec 2007 07:26:58 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20071202072658.A9217@xorpc.icir.org> References: <20071202055031.A8107@xorpc.icir.org> <19256.1196608121@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <19256.1196608121@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sun, Dec 02, 2007 at 03:08:41PM +0000 Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 15:28:15 -0000 On Sun, Dec 02, 2007 at 03:08:41PM +0000, Poul-Henning Kamp wrote: > In message <20071202055031.A8107@xorpc.icir.org>, Luigi Rizzo writes: > > > >This is why i suggest having a 'scale' that can represent '1 tick' > >(and also don't depend on TIMEOUT_MSEC == 1000 and so on, but keep > >them opaque and require that the client code uses one of the supported > >scales). > > > Using a deadline timer based in the HPET, the timeout can be scheduled > to any 1/14318181th of a second This must obviously come for a price or there would be no reason to provide 'millisecond' and 'second' precisions that you suggested. I agree that the API should not assume that the hardware is based on a periodic timer, but in the same way it should not assume that the hardware can generate arbitrary timeouts. Secondy: > and there will be no concept of "a > tick" as we know it now. > Clients should say how often they want to be called, and they should > express it in terms of time, not based on some implementation detail > of a historical implementation of the scheduler. "periodically with whatever period is convenient to you" is a legitimate request that client code might have. (I understand that this concept of time is very southern european :) It wouldn't make sense to do poll-based event handling at the same rate on a 133MHz soekris or on a 3 GHz multicore cpu. Even if you kick HZ out of your API, it will come back in some indirect form. In any case: in terms of API it costs absolutely nothing to support system-dependent resolutions instead of absolute ones, so i don't quite understand the opposition. cheers luigi