From owner-freebsd-arch@FreeBSD.ORG Sun Jan 25 21:29:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E4D16A4CE for ; Sun, 25 Jan 2004 21:29:37 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4485643D3F for ; Sun, 25 Jan 2004 21:29:36 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 21048 invoked from network); 26 Jan 2004 05:29:34 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 26 Jan 2004 05:29:34 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 25 Jan 2004 23:29:33 -0600 (CST) From: Mike Silbersack To: arch@freebsd.org Message-ID: <20040125230314.S730@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Updating callout_reset X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 05:29:37 -0000 Based on the work I've been doing with the rtc driver and some issues in the tcp stack with high hz values, I'd like to propose a change in the callout_reset interface. Currently, the timeout value is specified in ticks. This creates two problems: #1 - At high hz rates, the maximum timeout possible is reduced; we have at least one example of this causing problems in the kernel at present (16-bit sbtimeout values getting reduced from 327 to 32 seconds), there could be others we haven't caught. Many of these are likely to result from integer math errors introduced by authors who hadn't considered larger hz values occuring. #2 - Using ticks reduces the potential accuracy of wakeups with our default hz setting. For example, if one wishes to sleep for 5ms when hz=100, the only choices is to request one tick, or 10ms. However, if 5ms could be specified, the callout subsystem would be able to schedule more precise wakeups in places where the next timer interval was between 5 and 10ms away. Case #1 also provides a second justification for a change; any piece of code which requests a timeout must be aware of the system hz; moving to a standard time format would create more straightforward code. In order to ensure that modules and the like do not break, I would like to propose that we leave callout_reset defined as is and create a new function, callout_set (or some other clever name) which takes a struct *timespec in place of ticks. Optimizations as suggested in example #2 above would not be implemented right away, but would be possible due to the better interface. Thoughts? Mike "Silby" Silbersack