Re: [RFC/RFT] calloutng

On 06.01.2013 18:20, Luigi Rizzo wrote:
> On Sun, Jan 06, 2013 at 04:23:13PM +0100, Marius Strobl wrote:
>> On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote:
>>> Here is small tool we are using for test correctness and performance of 
>>> different user-level APIs: http://people.freebsd.org/~mav/testsleep.c
>>>
>>
>> I've run Ian's set of tests on a v215 with and without your
>> calloutng_12_26.patch and on a v210 (these uses the IPI approach)
>> with the latter also applied.
>> I'm not really sure what to make out of the numbers.
>>
>>                v215 w/o             v215 w/              v210 w/     
>> ---------- ----------------     ----------------     ----------------
>> select          1   1999.61          1     23.87          1     29.97
>> poll            1   1999.70          1   1069.61          1   1075.24
>> usleep          1   1999.86          1     23.43          1     28.99
>> nanosleep       1    999.92          1     23.28          1     28.66
>> kqueue          1   1000.12          1   1071.13          1   1076.35
>> kqueueto        1    999.56          1     26.33          1     31.34
>> syscall         1      1.89          1      1.92          1      2.88
>> select        300   1999.72        300    326.08        300    332.24
>> poll          300   1999.12        300   1069.78        300   1075.82
>> usleep        300   1999.91        300    325.63        300    330.94
>> nanosleep     300    999.82        300     23.25        300     26.76
>> kqueue        300   1000.14        300   1071.06        300   1075.96
>> kqueueto      300    999.53        300     26.32        300     31.42
>> syscall       300      1.90        300      1.93        300      2.89
>> select       3000   3998.18       3000   3176.51       3000   3193.86
>> poll         3000   3999.29       3000   3182.21       3000   3193.12
>> usleep       3000   3998.46       3000   3191.60       3000   3192.50
>> nanosleep    3000   1999.79       3000     23.21       3000     27.02
>> kqueue       3000   3000.12       3000   3189.13       3000   3191.96
>> kqueueto     3000   1999.99       3000     26.28       3000     31.91
>> syscall      3000      1.91       3000      1.91       3000      2.90
>> select      30000  30990.85      30000  31489.18      30000  31548.77
>> poll        30000  30995.25      30000  31518.80      30000  31487.92
>> usleep      30000  30992.00      30000  31510.42      30000  31475.50
>> nanosleep   30000   1999.46      30000     38.67      30000     41.95
>> kqueue      30000  30006.49      30000  30991.86      30000  30996.77
>> kqueueto    30000   1999.09      30000     41.67      30000     46.36
>> syscall     30000      1.91      30000      1.91      30000      2.88
>> select     300000 300990.65     300000 301864.98     300000 301787.01
>> poll       300000 300998.09     300000 301831.36     300000 301741.62
>> usleep     300000 300990.80     300000 301824.67     300000 301770.10
>> nanosleep  300000   1999.15     300000    325.74     300000    331.01
>> kqueue     300000 300000.87     300000 301031.11     300000 300992.28
>> kqueueto   300000   1999.39     300000    328.77     300000    333.45
>> syscall    300000      1.91     300000      1.91     300000      2.88
> 
> the nanosleep and kqueueto tests are probably passing the wrong
> argument to the syscall (meant to be microseconds, but nanosleep
> takes nanosecond so it should probably be multiplied by 1000).

Yes, you are right. I've used it in such way to see what will happen if
I request sub-microsecond interval. In this test these rows are
definitely incorrect.

> I think that for the time being it would be useful to run at least
> one set of tests with kern.timecounter.alloweddeviation=0 so we can
> tell how close we get to the required timeouts

May be just to be sure, because it should not significantly affect
results of the 1us tests, as 5% of 1us is much less then numbers we see
there.

-- 
Alexander Motin