On Fri, 24 Sep 2021, I wrote:
This is a patch series for QEMU that I started last year. The aim was to
try to get a monotonic clocksource for Linux/m68k guests. That hasn't
been achieved yet (for q800 machines). I'm submitting the patch series
because,
- it improves 6522 emulation fidelity, although slightly slower, and
I did some more benchmarking to examine the performance implications.
I measured a performance improvement with this patch series. For a
Linux/m68k guest, the execution time for a gettimeofday syscall dropped
from 9 us to 5 us. (This is a fairly common syscall.)
The host CPU time consumed by qemu in starting the guest kernel and
executing a benchmark involving 20 million gettimeofday calls was as
follows.
qemu-system-m68k mainline (42f6c9179b):
real 198 s
sys 123 s
user 73 s
sys/user 1.68
qemu-system-m68k patched (0a0bca4711):
real 112 s
sys 63 s
user 47 s
sys/user 1.34
As with any microbenchmark, this workload is not a real-world one. For
comparison, here are measurements of the time to fully startup and
immediately shut down Debian Linux/m68k SID (systemd):
qemu-system-m68k mainline (42f6c9179b)
real 31.5 s
sys 1.59 s
user 27.4 s
sys/user 0.06
qemu-system-m68k patched (0a0bca4711)
real 31.2 s
sys 1.17 s
user 27.6 s
sys/user 0.04
The decrease in sys/user ratio reflects the small cost that has to be paid
for the improvement in 6522 emulation fidelity and timer accuracy. But
note that in both benchmarks wallclock execution time dropped, meaning
that the system is faster overall.
The gettimeofday testing revealed that the Linux kernel does not properly
protect userland from pathological hardware timers, and the gettimeofday
result was seen to jump backwards (that was unexpected, though Mark did
predict it).
This backwards jump was often observed in the mainline build during the
gettimeofday benchmark and is result of bugs in mos6522.c. The patched
build did not exhibit this problem (as yet).
The two benefits described here are offered in addition to all of the
other benefits described in the patches themselves. Please consider
merging this series.