Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng

On Mon, Dec 17, 2012 at 12:17:54PM -0800, Davide Italiano wrote:
> On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo <rizzo_at_iet.unipi.it> 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 <rizzo_at_iet.unipi.it> 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_at_.
> >
> > 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