From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 21 20:24:28 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D295989F; Fri, 21 Feb 2014 20:24:28 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9196018E4; Fri, 21 Feb 2014 20:24:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6FEB47300A; Fri, 21 Feb 2014 21:26:37 +0100 (CET) Date: Fri, 21 Feb 2014 21:26:37 +0100 From: Luigi Rizzo To: Ian Lepore Subject: Re: What is the precision arg for callout_reset_sbt() and friends? Message-ID: <20140221202637.GC5118@onelab2.iet.unipi.it> References: <1393003465.1145.111.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393003465.1145.111.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:24:28 -0000 On Fri, Feb 21, 2014 at 10:24:25AM -0700, Ian Lepore wrote: > I can't figure out from the code or the manpage what should be passed as > the precision argument to the sleep-related functions that take sbintime > values. It seems like most existing code passes 0, what effect does > that have? What should I pass if precision really matters? What if it > doesn't matter at all? I was one of the people suggesting the addition of a 'precision' argument, the intent being to use it as a hint to help merge events and reduce the number of timer interrupts. Since pre-existing APIs did not have this parameter we used 0 when translating from the old to the new one. If you write something new of course you can express your needs as you suggest below. In practice i think the following issues partly reduce the usefulness of the parameter: - there is no way to express a precision from userspace so anything using select/poll/kqueue will end up with the 'standard' argument; - with large intervals, aggregation is not really a concern: events are likely to be scattered (so little chance of merging) and probably infrequent (so little gain from merging) - with short periodic intervals (where merging might save something), applications would prefer if the interval is reasonably accurate and has no drift. So I would expect to see a lot of precision=0 in clients of this type. - the implementation, for a delay D and precision P, seems to schedule a timeout after D+P unless one exists already in the interval D..D+P. This increases the chance of merging but is annoying for applications. I think we should do it differently i.e.: if nothing is scheduled in D..D+P then schedule a timeout after D (and not D+P). Then, in the data structure we should (hopefully it is already like this) keep both D and P so when we grab the next event from the timeout queue, we try to set the timer to a value that includes the largest number of intervals, using one of the D_i values (so that at least someone will get it close to the request). This might require a slightly different data structure than the timing wheel/heap or whatever is used now as a backend. cheers luigi > Most of the time I want something like a 1ms timeout where it really > isn't critical if it turns into 2 or even 5ms. Other times when I say > 1ms I really want something close to 1ms. > > -- Ian > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"