From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 21:12:33 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 DE114D98; Mon, 17 Dec 2012 21:12:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 95E458FC15; Mon, 17 Dec 2012 21:12:33 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D07967300A; Mon, 17 Dec 2012 22:11:12 +0100 (CET) Date: Mon, 17 Dec 2012 22:11:12 +0100 From: Luigi Rizzo To: Davide Italiano Subject: Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng Message-ID: <20121217211112.GA84347@onelab2.iet.unipi.it> References: <20121217192731.GA83405@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: 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: Mon, 17 Dec 2012 21:12:33 -0000 On Mon, Dec 17, 2012 at 12:17:54PM -0800, Davide Italiano wrote: > On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo wrote: > > [addressing the various items separately] > > > > On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote: > >> On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo wrote: > > ... > >> > - for several functions the only change is the name of an argument > >> > from "busy" to "us". Can you elaborate the reason for the change, > >> > and whether "us" means microseconds or the pronoun ?) > >> > > >> > >> Please see r242905 by mav@. > > > > i see the goal of this patch is to pass along the amount of > > time till the next timer. > > > > I wonder why the choice is to use (actually, call) the value > > "microseconds" rather use a bintime or something scaled and with a > > well defined resolution. > > > > In fact looking at the relevant diff > > > > http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905&r2=242904&pathrev=242905 > > > > cpu_idleclock() actually returns a value that is not even microseconds > > but 1/(2^20) seconds. The value seems to be ignored right now > > so it would be a good time to discuss the resolution. > > > > I am concerned that at some point (5 years from now perhaps ?) > > microseconds might start to become too coarse and we would like > > something with a more fine-grained resolution. On the > > other hand, for the purposes of this change, we can probably > > live with an upper limit of some seconds (waking up the machine > > once per second is not going to kill performance). > > > > I would talk more about power consumption problem rather than performances. > Yes, you're right because now, even with calloutng changes, the CPU is > woken up at least twice per second. > The wheel scan, in case it doesn't find a new callout to schedule in > the next half-second, schedules an interrupt half a second from "now" > (where now is the time obtained using getbinuptime()/binuptime()). > This is a threshold we set up empirically, and it resulted is "good" > for now. But in the future someone may raise the threshold to 1 > second, 10 seconds, or something like. So, I don't agree with your > statement. this is only an issue if we want to use 32 bits. If we go to 64 bits, there is enogh space for picoseconds on the fractional part, and a few years in the integer part. but keep in mind, even powerwise, i doubt the exit from deep sleep and a callout takes more than 500us so even doing that once per second gives less than 0.5 per mille increase in power compared to a machine that is always idle This is really noise that we should not worry about. cheers luigi