On 06/23/12 18:26, Bruce Evans wrote:
On Sat, 23 Jun 2012, Konstantin Belousov wrote:
On Sat, Jun 23, 2012 at 03:17:57PM +0200, Marius Strobl wrote:
So apart from introducing code to constantly synchronize the
TICK counters, using the timecounters on the host busses also
seems to be the only viable solution for userland. The latter
should be doable but is long-winded as besides duplicating
portions of the corresponding device drivers in userland, it
probably also means to get some additional infrastructure
like being able to memory map registers for devices on the
nexus(4) level in place ...
There is little point in optimizations to avoid syscalls for hardware.
On x86, a syscall takes 100-400 nsec extra, so if the hardware takes
500-2000 nsec then reduction the total time by 100-400 nsec is not
very useful.
Just out of curiosity I've run my own binuptime() micro-benchmarks:
- on Core i5-650:
TSC 11ns
HPET 433ns
ACPI-fast 515ns
i8254 3736ns
- on dual-socket Xeon E5645:
TSC 15ns
HPET 580ns
ACPI-fast 1118ns
i8254 3911ns
I think it could be useful to have that small benchmark in base kernel.
Understand. I do plan eventually to map HPET counters page into usermode
on x86.
This should be left out too.
Also, as I noted above, some code to synchronize per-package counters
would be useful for x86, so it might be developed with multi-arch
usage in mind.
It's only worth synchonizing fast timecounter hardware so that it can be
used in more cases. It probably needs to be non-bus based to be fast.
That means the TSC on x86.
The new timeout code to support tickless kernels looks like it will give
large pessimizations unless the timecounter is fast. Instead of using
the tick counter (1 atomic increment on every clock tick) and some
getbinuptime() calls in places like select(), it uses the hardware
timecounter via binuptime() in most places (since without a tick counter
and without clock interrupts updating the timehands periodically, it takes
a hardware timecounter read to determine the time). So callout_reset()
might start taking thousands of nsec for per call, depending on how slow
the timecounter is. This fix is probably to use a fuzzy time for long
long timeouts and to discourage use of short timeouts and/or to turn them
into long or fuzzy timeouts so that they are not very useful.
The new timeout code is still in active development and optimization was
not the first priority yet. My idea was to use much faster
getbinuptime() for periods above let's say 100ms. Legacy ticks-oriented
callout_reset() functions are by default not supposed to provide
sub-tick resolution and with some assumptions could use getbinuptime().
For new interfaces it depends on caller, how will it get present time.
I understand that integer tick counter is as fast as nothing else can
ever be. But sorry, 32bit counter doesn't fit present goals. To have
more we need some artificial atomicity -- exactly what getbinuptime()
implements. What I would like to see there is tc_tick removal to make
tc_windup() called for every hardclock tick. Having new tick-irrelevant
callout interfaces we probably won't so much need to increase HZ too
high any more, while this simplification would make ticks and
getbinuptime() precision equal, solving some of your valid arguments
against the last.
--
Alexander Motin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
