From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 15:54:50 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 6E18416A419 for ; Sun, 2 Dec 2007 15:54:50 +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 4D48E13C45D for ; Sun, 2 Dec 2007 15:54:50 +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 lB2FrYvb012488; Sun, 2 Dec 2007 07:53:34 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id lB2FrYpg012487; Sun, 2 Dec 2007 07:53:34 -0800 (PST) (envelope-from rizzo) Date: Sun, 2 Dec 2007 07:53:34 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20071202075334.A11104@xorpc.icir.org> References: <20071202072658.A9217@xorpc.icir.org> <19518.1196609689@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: <19518.1196609689@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sun, Dec 02, 2007 at 03:34:49PM +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:54:50 -0000 On Sun, Dec 02, 2007 at 03:34:49PM +0000, Poul-Henning Kamp wrote: > In message <20071202072658.A9217@xorpc.icir.org>, Luigi Rizzo writes: > >On Sun, Dec 02, 2007 at 03:08:41PM +0000, Poul-Henning Kamp wrote: > > >> 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. > > If the client code needs this finegrained control, the trick is to > extend the API to be able to provide this information somehow. > > But before designing that, we need to have concrete examples > to talk about. > > >"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 :) > > I disagree, that case, should be "with a period between N and M, > at your choice". yes surely this is better. But since your initial interface only had one parameter for this i tried to stick with that. > And yes, it may be that we need to extend the API for that, but > please give a concrete example so we know what we're talking about. DEVICE_POLLING is one example. You poll (and do resource allocation) to avoid livelock generated by too many interrupts, but don't know in advance what's the correct polling rate so rely on the system administrator to set HZ appropriately. (the same might apply for devices with broken or missing interrupt hardware so you have to poll. You'd trash them in an ideal world, but sometimes you have to live with them). dummynet is another one - in principle you'd like precise timing but with thousands of active pipes you probably can't afford that and so again rely on some coarser resolution which is synchronized with some system task. > >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. > > Hz is the same for those two, so today we poll at the same rate. but you'd bump HZ to 2k or 4k up on a modern CPU, and lower to 500 on a soekris. > >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. > > I'm applying Jim Gettys 3. rule from the X11 project: > > 3.The only thing worse than generalizing from one example > is generalizing from no examples at all. for what matters that would apply to the ns/us/ms/s resolutions that you proposed. They may be intuitive units but it doesn't mean that they are the most appropriate ones. Anyways, I think you got my point. cheers luigi