From owner-freebsd-arch@FreeBSD.ORG Mon Jul 14 15:04:06 2003 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 7FA9037B401; Mon, 14 Jul 2003 15:04:06 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B70F943F93; Mon, 14 Jul 2003 15:04:04 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id IAA02746; Tue, 15 Jul 2003 08:04:02 +1000 Date: Tue, 15 Jul 2003 08:04:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Josef Karthauser In-Reply-To: <20030714190514.GA3270@genius.tao.org.uk> Message-ID: <20030715072847.S9776@gamplex.bde.org> References: <20030714190514.GA3270@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: Importing 'mstohz' from NetBSD. 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, 14 Jul 2003 22:04:06 -0000 On Mon, 14 Jul 2003, Josef Karthauser wrote: > It looks like NetBSD have a net function defined in the kernel. > > --- param.h 2002/03/17 19:43:07 1.137 > +++ param.h 2002/04/05 18:27:57 1.138 > @@ -1,4 +1,4 @@ > -/* $NetBSD: param.h,v 1.136 2002/03/09 01:42:13 thorpej Exp $ */ > +/* $NetBSD: param.h,v 1.137 2002/03/17 19:43:07 atatat Exp $ */ > > /*- > * Copyright (c) 1982, 1986, 1989, 1993 > @@ -274,5 +274,20 @@ > #ifndef UBC_NWINS > #define UBC_NWINS 1024 > #endif > + > +#ifdef _KERNEL > +/* > + * macro to convert from milliseconds to hz without integer overflow > + * Default version using only 32bits arithmetics. > + * 64bit port can define 64bit version in their > + * 0x20000 is safe for hz < 20000 > + */ > +#ifndef mstohz > +#define mstohz(ms) \ > + (__predict_false((ms) >= 0x20000) ? \ > + ((ms +0u) / 1000u) * hz : \ > + ((ms +0u) * hz) / 1000u) > +#endif > +#endif /* _KERNEL */ > > #endif /* !_SYS_PARAM_H_ */ > > They have replaced TICKS_TO_HZ with calls to 'mstohz' in the usb stack > as well as in other places. Is this something that we want to do also? I think you mean a new function that replaces the usb-specific macro MS_TO_TICKS() by general interface named mstohz(). (The new interface is no different except for its name, but its implementation doesn't give undefined behaviour on overflow.) I think the new interface should be kept in usb for now. The kernel has to many representations of times, and milliseconds is not particularly common, convenient or good. The macro shouldn't be defined in since it is not a parameter; it is only defined there to give it global scope. I wouldn't bother micro-optimizing it, including making it a macro instead of a function; it is probably not needed in [m]any fast paths, and the multiplications and divisions in it probably take longer than function a call. Anyway, we don't bother micro-optimizing the similar tvtohz() function. NetBSD doesn't seem to have tvtohz(), but it has the slightly different hzto() function with a similar implementation optimized for correctness more than speed. The non-(time-)optimization of these functions hasn't proved to be noticeable. tvtohz() is more than slightly easier to use than hzto(); mstohz() can easily be implemented on top of hzto() by converting from millseconds to a timeval and passing the timeval to tvtohz(). This would give a very correct implementation in a simple way at some cost in efficiency. Starting from scratch, I would use common units much smaller than a 1/hz tick or a millisecond for most times in the kernel. Old interfaces like timeout() still get some benefits on some machines by using only 32-bit counters, but these benefits will become negative when 32-bit machine go away. Bruce