svn commit: r236449 - projects/calloutng/sys/kern

[Davide Italiano]

On Sat, Jun 2, 2012 at 4:16 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Sat, 2 Jun 2012, Davide Italiano wrote:
>
>> Log:
>>  Replace binuptime() with getbinuptime() because it's suitable for the
>>  purpose and it's cheaper. Update the relative comment on precision error
>>  during callwheel scan as well.
>
>
> This makes even less sense than converting to bintimes at all.
> getbinuptime() can give an even lower precision than the current timer
> ticks, since it is only updated every tc_tick/hz seconds while ticks
> are updated every 1/hz seconds.  Also, you have to keep timeouts firing
> for getbintime() to work.  OTOH, bintime() is unusable in timeout code,
> since it may be too inefficient, depending on the timecounter hardware.
> cpu_ticks() might be usable.  It doesn't use bintimes and isn't very
> accurate, but these are other bugs which become features for use here.
>
>
>> Modified: projects/calloutng/sys/kern/kern_timeout.c
>>
>> ==============================================================================
>> --- projects/calloutng/sys/kern/kern_timeout.c  Sat Jun  2 12:26:14 2012
>>      (r236448)
>> +++ projects/calloutng/sys/kern/kern_timeout.c  Sat Jun  2 13:04:50 2012
>>      (r236449)
>> @@ -373,9 +373,9 @@ callout_tick(void)
>>        need_softclock = 0;
>>        cc = CC_SELF();
>>        mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET);
>> -       binuptime(&now);
>> +       getbinuptime(&now);
>>        /*
>> -        * Get binuptime() may be inaccurate and return time up to 1/HZ in
>> the past.
>> +        * getbinuptime() may be inaccurate and return time up to 1/HZ in
>> the past.
>>         * In order to avoid the possible loss of one or more events look
>> back 1/HZ
>>         * in the past from the time we last checked.
>>         */
>
>
> Up to tc_tick/hz, not up to 1/HZ.  tc_tick is the read-only sysctl
> variable kern.timecounter.tick that is set to make tc_tick/hz as close
> to 1 msec as possible.  If someone asks for busy-waiting by setting
> HZ to much larger than 1000 and uses this to generate lots of timeouts,
> they probably get this now, but get*time() cannot be used even to
> distingish times differing by the timeout granularity.  It is hard to
> see how it could ever work for the above use (timout scheduling with
> a granularity of ~1/hz when you can only see differences of ~tc_tick/hz,
> with tc_tick quite often 4-10, or 100-1000 to use or test corner
> cases??).  With a tickless kernel, timeouts wouldn't have a fixed
> granularity, but you need accurate measurements of times even more.
> One slow way to get them is to call binuptime() again in the above.
> Another, even worse way to update timecounters after every timeout
> expires (the update has a much higher overhead than binuptime(), so
> this will be very slow iff timeouts that expire are actually used).
>
> I noticed too many style bugs to describe in previous changes in this
> area.  The above only shows formatting for 85-column terminals.

Bruce,
I'm happy you looked at my commit, and I'm ready to look to fix them
if you want to help me notifying where I'm wrong with style.

>
> Bruce

Davide