1. 13 May, 2012 1 commit
  2. 08 May, 2012 1 commit
  3. 02 May, 2012 1 commit
    • Stefan Weil's avatar
      qemu-timer: Fix limits for w32 mmtimer · 40f08e87
      Stefan Weil authored
      timeSetEvent only accepts delays in the range which is returned by
      The lower limit is typically 1 (= 1 ms), so the constant value of 1
      in the old code usually worked.
      The upper limit can be as low as 10000 ms, so the latest changes in
      QEMU's timer handling which introduced timeout values above that limit
      could result in failures of timeSetEvent when the timer was re-armed.
      Signed-off-by: default avatarStefan Weil <sw@weilnetz.de>
  4. 26 Apr, 2012 8 commits
  5. 16 Apr, 2012 1 commit
    • Peter Portante's avatar
      qemu-timer.c: Remove 250us timeouts · 158fd3ce
      Peter Portante authored
      Basically, the main wait loop calls qemu_run_all_timers() unconditionally. The
      first thing this routine used to do is to see if a timer had been serviced,
      and then reset the loop timeout to the next deadline.
      However, the new deadlines had not been calculated at that point, as
      qemu_run_timers() had not been called yet for each of the clocks. So
      qemu_rearm_alarm_timer() would end up with a negative or zero deadline, and
      default to setting a 250us timeout for the loop.
      As qemu_run_timers() is called for each clock, the real deadlines would be put
      in place, but because a loop timeout was already set, the loop timeout would
      not be changed.
      Once that 250us timeout fired, the real deadline would be used for the
      subsequent timeout.
      For idle VMs, this effectively doubles the number of times through the loop,
      doubling the number of select() system calls, timer calls, etc. putting added
      scheduling pressure on the kernel. And under cgroups, this really causes a big
      problem because the cgroup code does not scale well.
      By simply running the timers before trying to rearm the timer, we always rearm
      with a non-zero deadline, effectively halving the number of system calls.
      Signed-off-by: default avatarPeter Portante <pportant@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  6. 30 Mar, 2012 1 commit
  7. 17 Feb, 2012 1 commit
  8. 26 Jan, 2012 1 commit
  9. 09 Nov, 2011 1 commit
  10. 21 Oct, 2011 8 commits
  11. 15 Sep, 2011 2 commits
  12. 02 Sep, 2011 1 commit
    • Anthony Liguori's avatar
      main: force enabling of I/O thread · 12d4536f
      Anthony Liguori authored
      Enabling the I/O thread by default seems like an important part of declaring
      1.0.  Besides allowing true SMP support with KVM, the I/O thread means that the
      TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
      currently requires a (racey) signal based alarm system.
      I know there have been concerns about performance.  I think so far the ones that
      have come up (virtio-net) are most likely due to secondary reasons like
      decreased batching.
      I think we ought to force enabling I/O thread early in 1.0 development and
      commit to resolving any lingering issues.
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  13. 20 Aug, 2011 1 commit
  14. 23 Jul, 2011 3 commits
  15. 06 Jun, 2011 1 commit
  16. 27 Apr, 2011 3 commits
  17. 15 Apr, 2011 3 commits
  18. 21 Mar, 2011 2 commits
    • Paolo Bonzini's avatar
      remove qemu_get_clock · 6d5ad9bf
      Paolo Bonzini authored
      These patches are already not doing a great service to out-of-tree
      modifications to QEMU.  However, at least we can warn them by getting
      rid of the old confusing functions, or otherwise causing compilation
      errors.  This patch removes qemu_get_clock; the previous one changed
      qemu_new_timer's signature.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    • Paolo Bonzini's avatar
      add a generic scaling mechanism for timers · 4a998740
      Paolo Bonzini authored
      This enables rt_clock timers to use nanosecond resolution, just by
      using the _ns functions; there is really no reason to forbid that.
      Migrated timers are all using vm_clock (of course; but I checked that
      anyway) so the timers in the savevm files are already in nanosecond
      resolution.  So this patch makes no change to the migration format.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>