Re: Understanding PR kern/43997 (kernel timing problems / qemu)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 30 Jul 2017 13:01:50 +0300
    From:        Andreas Gustafsson <gson%gson.org@localhost>
    Message-ID:  <22909.44686.188004.117151%guava.gson.org@localhost>

  | I don't think the slowness of qemu's emulation is the actual cause of
  | its inability to simulate clock interrupts at 100 Hz.

Yes, I was wondering about that, as if it was, there'd often be no time
left for anything else...

  | If my theory is correct, there are at least three ways the problem
  | could be fixed:
  | 
  |  - Improve the time resolution of sleeps on the host system,
  |  - Make qemu deal better with hosts unable to sleep for short periods

Either, or both, of those should be fixed, and I might get to take a
look at the first one (the insides of qemu are not all that appealing...)
but

  |  - Make the guest system deal better with missed timer interrupts.

This one needs to be fixed. an idle system that says it takes 13 seconds
to do a sleep 10 is simply broken.  Fixing the other issues (or either
one of them) would make it much harder to work on this one - that is
keeping the qemu/host relationship stable allows a platform where the
timekeeping issues in the kernel are known to occur, so a good way to
verify any fix, so I think this should be fixed first.

kre