On Saturday, 04.07.2015 at 16:06, Antti Kantee wrote: > On 04/07/15 15:47, Martin Lucina wrote: > >Interesting. Perhaps your QEMU is showing even more overhead for PIT > >interrupt delivery than mine? > > So you can't repeat the problem? Interesting. > > pooka@watou:~$ qemu-system-x86_64 --version > QEMU emulator version 2.1.0 (Debian 2.1+dfsg-4ubuntu6.7), Copyright > (c) 2003-2008 Fabrice Bellard > > >Can you run the test program below with, say, '10 500', '10 1000' and '10 > >5000' as parameters and report the output? Also, if possible, run it in > >both POSIX mode and BMK mode (built with -DBMK, you'll need to comment out > >the "die" if the stub link fails in -gcc). > > Not sure if evident from the data: that program also runs slow over > the wall clock in both modes. (not sure if expected or not)
I'm not sure what you mean by that. The wall clock value is informative in that the test program always sleeps a fixed amount and doesn't attempt to account for overhead, so the wall clock will diverge if the overheads are high. > POSIX mode: This looks fine, the overheads are in X ticks of the rump kernel HZ which is what I expected. I will try and reduce X, but that is a separate problem. > BMK mode: Bizarre. The problem is not related to QEMU -- running on baremetal x86_64 produces the same behaviour. I've checked all the likely culprits (pit_mult and tsc_mult values) and those are all fine. I'll keep digging, looks like I'll have to wait until tomorrow morning as the cacophony of discos from the other side of the lake has started at 10am, impossible to concentrate :-( Incidentally, does remote debugging on QEMU/x86_64 work for you? On my system it seems completely broken (endless series of "program interrupted with SIGTRAP" during BIOS boot).
