From owner-freebsd-arch@FreeBSD.ORG Wed Dec 19 15:44:31 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75623646; Wed, 19 Dec 2012 15:44:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by mx1.freebsd.org (Postfix) with ESMTP id 92A7B8FC14; Wed, 19 Dec 2012 15:44:30 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id jf3so1077931bkc.23 for ; Wed, 19 Dec 2012 07:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Q+HCfy6mvCBs/gmeiWofRAlvBBzh+GP4niu6XB1oumw=; b=Bb800yhX0+Ylcu5xxGH736OvrPQxaTW7f8srbZb4a1C7lqeWm2RWZYe1LaIKTkVsPm S1DnQo30T4vtlYPCUwR8m59+rjcKlZ020SGCERuY7ha9H8UhnQpur+M9UHS2GP5xwWSk jgN4dp4uPupes0Zc6191o2E4bhxogbM2fKm4B9Xtcz+fh2tD+9uTtKn42m2QY0g68iQ4 0Rqv0wqc3WIykm/BTcagXokSmEX/bF3f6rKfCdofOeiKo+v9MTjDRlBz0yOSG+KQgv5X ZWbg4/vZuG1fbjE7vI/L9NHAu4HNxo6IGe5QcGN4Kadt8+DuzEpMVa0O55QUFXZGFnP3 PShg== X-Received: by 10.204.5.145 with SMTP id 17mr2763593bkv.98.1355931868799; Wed, 19 Dec 2012 07:44:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id o9sm4615748bko.15.2012.12.19.07.44.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 07:44:27 -0800 (PST) Sender: Alexander Motin Message-ID: <50D1E0D8.9070209@FreeBSD.org> Date: Wed, 19 Dec 2012 17:44:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans Subject: Re: API explosion (Re: [RFC/RFT] calloutng) 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> <20121220010702.B1675@besplex.bde.org> In-Reply-To: <20121220010702.B1675@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , phk@onelab2.iet.unipi.it, Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:44:31 -0000 On 19.12.2012 16:20, Bruce Evans wrote: > On Wed, 19 Dec 2012, Davide Italiano wrote: > >> On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans >> wrote: > >>> 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. > > In the old API, it is an error to pass ticks < 0, so only broken old > callers are affected. Of course, if there are any then it would be > hard to detect their garbage cookies. > > Anywy, it's too later to change to this, and maybe also to a 32.32 > format. It would be late to change this after committing. I would definitely like it to be done earlier to not redo all the tests, but I think we could convert callout and eventtimers code to 32.32 format in several days. The only two questions are: do we really want it (won't there be any reasons to regret about it) and how do we want it to look? For the first question my personal showstopper since eventtimers creation always was the wish to keep consistency. But benefits of 32.32 format are clear, and if there are more votes for it, let's consider. If now it will be decided that full range will never be useful for callout subsystem, then it is obviously not needed for eventtimers also. About the second question, what do you think about such prototypes: typedef int64_t sbintime_t static __inline sbintime_t bintime_shrink(struct bintime *bt) {} static __inline struct bintime bintime_expand(sbintime_t sbt) {} ... int callout_reset_bt(struct callout *, sbintime_t sbt, sbintime_t pr, void (*fn)(void *), void *arg, int flags); , where pr used only for absolute precision, and flags includes: direct execution, absolute/relative time in argument, relative precision in case of relative sbt, flag for aligning to hardclock() to emulate legacy behavior, and potentially flags for reaction on suspend/resume. Another option is to move absolute precision also to flags, using log2() representation, as we tried and as was proposed before. With possibility to use precise relative time there will be few cases requiring absolute value of precision, that should depend on period. Then there will be no extra arguments in the most usual cases. Wrapper for existing API compatibility will look just like this: #define callout_reset(c, ticks, fn, arg) \ callout_reset_bt(c, ticks2sbintime(ticks), -1, \ (fn), (arg), C_HARDCLOCK) -- Alexander Motin