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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
