From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 13:05:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50B1F714; Wed, 19 Dec 2012 13:05:08 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id AED108FC0C; Wed, 19 Dec 2012 13:05:07 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so2209257vbi.4 for ; Wed, 19 Dec 2012 05:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MX5cw1qHYhNlodpk7btfMXKeyR7NnCm68rmxmtC5ebg=; b=Z2/gXbAKOyEmkjIzySBTvavzH4mRlpyHpZqD+PfPzf2mTNEcFgHLhmNixEwLYClvDQ 0TMQHVRslhhdWkuJkVhdsA6aRRAVfAs3WD15fN+ZuoAAnplMo3jJ9Z7DjKvSsxcuoU/K Keo+0jMcH+lVipoNmhVVuZSiNiYxOjgxVT4wnHgo2WkNbqqMGh4dM844ad1x2mJNgrDA GwoX9OqYerjEXQghNBuq+8Pd1VLv0olpNn83sSQK5Kc4AmbM2TQAdpAR3KajBKQnKZzJ 8oXCkZjr5TcHQGJAerXKcsFIi18EOnwFMJ53JNKcL8v8yKcBm+mS41WHuPkbPbp7GpCZ SMdg== MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr7575902vdt.30.1355922306590; Wed, 19 Dec 2012 05:05:06 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.229.136 with HTTP; Wed, 19 Dec 2012 05:05:06 -0800 (PST) In-Reply-To: <20121219221518.E1082@besplex.bde.org> References: <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <15882.1355914308@critter.freebsd.dk> <20121219221518.E1082@besplex.bde.org> Date: Wed, 19 Dec 2012 05:05:06 -0800 X-Google-Sender-Auth: 0-_PGXea5bUURKIlbagvU5Ucxbs Message-ID: Subject: Re: API explosion (Re: [RFC/RFT] calloutng) From: Davide Italiano To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:05:08 -0000 On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans wrote: > On Wed, 19 Dec 2012, Poul-Henning Kamp wrote: > >> -------- >> In message >> >> , Davide Italiano writes: >> >>> Right now -- the precision is specified in 'bintime', which is a binary >>> number. >>> It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in >>> the specific platform. >> >> >> And that is way overkill for specifying a callout, at best your clock >> has short term stabilities approaching 1e-8, but likely as bad as 1e-6. > > > So you always agreed with me that bintimes are unsuitable for almost > everything, and especially unsuitable for timeouts? :-) > > >> (The reason why bintime is important for timekeeping is that we >> accumulate timeintervals approx 1e3 times a second, so the rounding >> error has to be much smaller than the short term stability in order >> to not dominate) > > > bintimes are not unsuitable for timekeeping, but they a painful to use > for other APIs. You have to either put bintimes in layers in the other > APIs, or convert them to a more suitable format, and there is a problem > placing the conversion at points where it is efficient. This thread > seems to be mostly about putting the conversion in wrong places. My > original objection was about using bintimes for almost everything at > the implementation level. > > >>> I do not really think it worth to create another structure for >>> handling time (e.g. struct bintime32), as it will lead to code >> >> >> No, that was exactly my point: It should be an integer so that >> comparisons and arithmetic is trivial. A 32.32 format fits >> nicely into a int64_t which is readily available in the language. > > > I would have tried a 32 bit format with a variable named 'ticks'. > Something like: > - ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use > this. The tick period would be constant but for virtual ticks and > not too small. hz = 1000 now makes the period too small, and not a > power of 2. So make the period 1/128 second. This gives a 1.24.7 > binary format. 2**24 seconds is 194 days. > - ticks < 0. The 31 value bits are now a cookie (descriptor) referring > to a bintime or whatever. This case should rarely be used. I don't > like it that a tickless kernel, which is needed mainly for power > saving, has expanded into complications to support short timeouts > which should rarely be used. > Bruce, I don't really agree with this. The data addressed by cookie should be still stored somewhere, and KBI will result broken. This, indeed, is not real problem as long as current calloutng code heavily breaks KBI, but if that was your point, I don't see how your proposed change could help. > >> As I said in my previous email: >> >> typedef dur_t int64_t; /* signed for bug catching */ >> #define DURSEC ((dur_t)1 << 32) >> #define DURMIN (DURSEC * 60) >> #define DURMSEC (DURSEC / 1000) >> #define DURUSEC (DURSEC / 10000000) >> #define DURNSEC (DURSEC / 10000000000) >> >> (Bikeshed the names at your convenience) >> >> Then you can say >> >> callout_foo(34 * DURSEC) >> callout_foo(2400 * DURMSEC) >> or >> callout_foo(500 * DURNSEC) > > > Constructing the cookie for my special case would not be so easy. > > >> With this format you can specify callouts 68 years into the future >> with quarter nanosecond resolution, and you can trivially and >> efficiently compare dur_t's with >> if (d1 < d2) > > > This would make a better general format than timevals, timespecs and > of course bintimes :-). It is a bit wasteful for timeouts since > its extremes are rarely used. Malicious and broken callers can > still cause overflow at 68 years, so you have to check for it and > handle it. The limit of 194 days is just as good for timeouts. > > Bruce I think the phk's proposal is better. About your overflow objection, I think is really unlikely to happen, but better safe than sorry. Thanks Davide