From owner-freebsd-arch@FreeBSD.ORG Wed Dec 19 08:34:46 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 8E15B48D; Wed, 19 Dec 2012 08:34:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id B50A88FC0C; Wed, 19 Dec 2012 08:34:45 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so997337wib.1 for ; Wed, 19 Dec 2012 00:34:39 -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=DadxxGdYJHOV3q/w6EouO8LdB8CbMOLMQf5BpToPM1E=; b=s50Z4udQ6HeeDIGg5napEbdv8lah3hPMbzf/nlG5xwMD6g+73iSGwMtqqB+HNajOca H3GLWdg53OE2ZxEx6clVchLC4moT/DsKTuMntsQpOUOHyY0+K2vNIGD//beVOcr5coH+ 0PduBSki1Tk1HvBIbFaJ6kmugYhlZ+2QXF94k6KSgk5MEmnyxRZqmtc+KvHR/hGetI49 Q/xeLC9wSaPIxKjZmKDwnS0jlsuSqQaMCzQr35l21E8qyvNo8cI3zq3Ra5QAEJWnzYwc mXAeTLzvI4tyxh9bcQOuV6x3XvdmyIc9ncx1xfe0J7jVL95/kU5eDAHjZqiMizOD/uHr NH/g== X-Received: by 10.194.122.98 with SMTP id lr2mr9798965wjb.55.1355906079195; Wed, 19 Dec 2012 00:34:39 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id l5sm6806692wia.10.2012.12.19.00.34.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 00:34:38 -0800 (PST) Sender: Alexander Motin Message-ID: <50D17C1B.8010207@FreeBSD.org> Date: Wed, 19 Dec 2012 10:34:35 +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: Ian Lepore 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> <20121218232955.GA97440@onelab2.iet.unipi.it> <1355873830.1198.189.camel@revolution.hippie.lan> In-Reply-To: <1355873830.1198.189.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , 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 08:34:46 -0000 On 19.12.2012 01:37, Ian Lepore wrote: > On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: >> On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: >>> On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: >>>> [top posting for readability; >>>> in summary we were discussing the new callout API trying to avoid >>>> an explosion of methods and arguments while at the same time >>>> supporting the old API and the new one] >>>> (I am also Cc-ing phk as he might have better insight >>>> on the topic). >>>> >>>> I think the patch you propose is a step in the right direction, >>>> but i still remain concerned by having to pass two bintimes >>>> (by reference, but they should really go by value) >>>> and one 'ticks' value to all these functions. >>>> >>>> I am also dubious that we need a full 128 bits to specify >>>> the 'precision': there would be absolutely no loss of functionality >>>> if we decided to specify the precision in powers of 2, so a precision >>>> 'k' (signed) means 2^k seconds. This way 8 bits are enough to >>>> represent any precision we want. >> >> ... >>> I'm not so sure about the 2^k precision. You speak of seconds, but I >>> would be worrying about sub-second precision in my work. It would >>> typical to want a 500uS timeout but be willing to late by up to 250uS if >> >> i said k is signed so negative values represent fractions of a >> second. 2^-128 is pretty short :) > > Ahh, I missed that. Good enough then! Hmmm, if that ideas survives > further review, then could precision be encoded in 8 bits of the flags, > eliminating another parm? Those who tracked the branch could see that actually was our first approach to handle precision. Unfortunately, it appeared not very convenient when you need to convert relative precision in percents or fraction of interval to the absolute precision in power of 2. We were worried that using some ffsll() for it can be inconvenient or expensive. But since we are now talking about passing relative bintime as an argument, that may be more viable option. I'll make another try. Thanks for the input. Pity it didn't happen couple of months ago. -- Alexander Motin