From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 03:05:42 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 020BC16A4CE for ; Mon, 26 Jan 2004 03:05:42 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 155D843D1D for ; Mon, 26 Jan 2004 03:05:40 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i0QB5cLE008575; Mon, 26 Jan 2004 22:05:38 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0QB5aEf014072; Mon, 26 Jan 2004 22:05:37 +1100 Date: Mon, 26 Jan 2004 22:05:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mike Silbersack In-Reply-To: <20040125230314.S730@odysseus.silby.com> Message-ID: <20040126212725.E1244@gamplex.bde.org> References: <20040125230314.S730@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: 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 11:05:42 -0000 On Sun, 25 Jan 2004, Mike Silbersack wrote: > #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. Changing the interface wouldn't fix this, but would introduce new overflow possibilities (when the caller passes a timeout that cannot be represented as in "int" tick count). > #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. Converting from another format to a tick count in callout_reset() would be a good pessimization. Fine tuning the timeout would be a better pessimization. callout_reset() is designed to be very efficient, partly by not looking at its timeout arg. The code to decide how near the next tick is would have to make at least an expensive binuptime() call. > 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. This is a negative justification. Unless you reimplement callouts and make them slower, callers must be aware of their limits to use them efficiently and avoid representation problems. Many callers don't worry much about efficiency and do calculations like (hz / 10) to get the timeout. This is still more efficient than the 64-bit divisions and other complications needed to handle general conversions of times to timeouts. (Look at tvtohz(). Note that the complications in it have very little to do with struct timeval not being a scalar type. They are to handle representation problems.) Bruce