Re: [RFC/RFT] calloutng

On 26.12.2012 01:21, Marius Strobl wrote:
> On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
>> Experiments with dummynet shown ineffective support for very short
>> tick-based callouts. New version fixes that, allowing to get as many
>> tick-based callout events as hz value permits, while still be able to
>> aggregate events and generating minimum of interrupts.
>>
>> Also this version modifies system load average calculation to fix some
>> cases existing in HEAD and 9 branches, that could be fixed with new
>> direct callout functionality.
>>
>> http://people.freebsd.org/~mav/calloutng_12_17.patch
>>
>> With several important changes made last time I am going to delay commit
>> to HEAD for another week to do more testing. Comments and new test cases
>> are welcome. Thanks for staying tuned and commenting.
>
> FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a
> try on sparc64 and it at least survives a buildworld there. However,
> with the patched kernels, buildworld times seem to increase slightly but
> reproducible by 1-2% (I only did four runs but typically buildworld
> times are rather stable and don't vary more than a minute for the
> same kernel and source here). Is this an expected trade-off (system
> time as such doesn't seem to increase)?

I don't think build process uses significant number of callouts to 
affect results directly. I think this additional time could be result of 
the deeper next event look up, done by the new code, that is practically 
useless for sparc64, which effectively has no cpu_idle() routine. It 
wouldn't affect system time and wouldn't show up in any statistics 
(except PMC or something alike) because it is executed inside timer 
hardware interrupt handler. If my guess is right, that is a part that 
probably still could be optimized. I'll look on it. Thanks.

> Is there anything specific to test?

Since the most of code is MI, for sparc64 I would mostly look on related 
MD parts (eventtimers and timecounters) to make sure they are working 
reliably in more stressful conditions.  I still have some worries about 
possible deadlock on hardware where IPIs are used to fetch present time 
from other CPU.

Here is small tool we are using for test correctness and performance of 
different user-level APIs: http://people.freebsd.org/~mav/testsleep.c

-- 
Alexander Motin