[RFC/RFT] calloutng
Alexander Motin
mav at FreeBSD.org
Tue Jan 8 10:55:38 UTC 2013
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
More information about the freebsd-arch
mailing list