Date: Mon, 26 Jan 2004 22:05:37 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mike Silbersack <silby@silby.com> Cc: arch@freebsd.org Subject: Re: Updating callout_reset Message-ID: <20040126212725.E1244@gamplex.bde.org> In-Reply-To: <20040125230314.S730@odysseus.silby.com> References: <20040125230314.S730@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040126212725.E1244>