From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 14:03:06 2013 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 9388A5B5; Wed, 2 Jan 2013 14:03:06 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA3B8FC08; Wed, 2 Jan 2013 14:03:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r02E2waO021163; Wed, 2 Jan 2013 07:02:58 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r02E2sIQ087850; Wed, 2 Jan 2013 07:02:54 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFC/RFT] calloutng From: Ian Lepore To: Alexander Motin In-Reply-To: References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> Content-Type: text/plain; charset="koi8-r" Date: Wed, 02 Jan 2013 07:02:54 -0700 Message-ID: <1357135374.54953.150.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Davide Italiano , Marius Strobl , FreeBSD Current , Luigi Rizzo , 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, 02 Jan 2013 14:03:06 -0000 On Wed, 2013-01-02 at 15:11 +0200, Alexander Motin wrote: > 02.01.2013 14:28 пользователь "Luigi Rizzo" написал: > > > > On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: > > > On 02.01.2013 12:57, Luigi Rizzo wrote: > > First of all, if you know that there is already a hardclock/statclock/* > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > a new one. > > That is true, but my main point was about merging with external events, > which I can't predict and the only way to merge is increase sleep period, > hoping for better. > This really is the crux of the problem, because you can't *by default* dispatch an event earlier than requested because that's just a violation of the usual rules of precision timing (where you expect to be late but never early). Sometimes there is no need for such precision, and an early wakeup is no more or less detrimental than a late wakeup. In fact, that may even be the majority case. I wonder if it might make sense to allow the precision specification to indicate whether it needs traditional "never early" behavior or whether it can be interpretted as "plus or minus this amount is fine." Like maybe negative precision is interpretted as "plus or minus abs(precision)" or something like that. Or maybe even the other way around... you get "plus or minus" precision by default and the few things that really care about precision timing have a way of indicating that. (But in that case the userland sleeps would have to assume the traditional behavior because that's how they've always been documented.) -- Ian