From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 15:54:41 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 8B53316A420 for ; Sun, 2 Dec 2007 15:54:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 468AD13C44B for ; Sun, 2 Dec 2007 15:54:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lB2FnrLf070803; Sun, 2 Dec 2007 08:49:53 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 02 Dec 2007 08:53:16 -0700 (MST) Message-Id: <20071202.085316.723205116.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <19256.1196608121@critter.freebsd.dk> References: <20071202055031.A8107@xorpc.icir.org> <19256.1196608121@critter.freebsd.dk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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:41 -0000 In message: <19256.1196608121@critter.freebsd.dk> "Poul-Henning Kamp" writes: : 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 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. Yes. I'd definitely like to move to this sort of thing. I missed the conversion routines in my last email, so ignore that part of things... Does this mean that you're planning a so-called tickless implementation? Warner