Re: [libvirt] "Choose alarm timer" feature for kvm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Mittwoch, den 27.08.2008, 11:28 +0100 schrieb Richard W.M. Jones:
> On Sun, Aug 24, 2008 at 08:20:05PM +0100, Daniel P. Berrange wrote:
> > On Sun, Aug 24, 2008 at 08:40:46PM +0200, Tiziano M?ller wrote:
> > > Hi everyone
> > > 
> > > In KVM it is possible to select the alarm timer being used (dynticks,
> > > hpet, rtc, unix).
> > 
> > What exactly do these options do ? Is there anything describing the
> > pros/cons of the different options & is there a way to determine 
> > what the best option is for a particular VM ? 
> 
> I've had a long look at the source code in KVM-73 associated with
> these timers and have some comments:
> 
> - QEMU tests the available timer sources in order and chooses the
> first one which works (allegedly the "best" one).  The order, on
> Linux, is:
> 
>    Timer          Implementation method
>    ---------------------------------------------------------------
>    (1) dynticks   POSIX timer_create
>    (2) hpet       Linux-specific hardware (/dev/hpet) - see below
>    (3) rtc        old /dev/rtc, millisecond accuracy
>    (4) "unix"     POSIX setitimer
> 
> - Dynticks is at the top of the list, and has an extra 'rearm'
> operation (the others only support starting and stopping timers).  But
> I don't understand how this rearm operation is an improvement.
> 
> - HPET is second in the list and most accurate.  It's backed by
> hardware and has sub-microsecond accuracy.
> 
> - It's not clear if dynticks (== timer_create) uses HPET internally in
> the kernel?
> 
> - I can't see how any of this would affect guests -- except that
> choosing a more accurate timer would be in some way 'better' because
> the guest would then get more accurate emulation events.
> 
> > Basically I'm wondering where/if this should be exposed in the XML
> > format, or whether libvirt could/should just internally pick the 
> > best one ?
> 
> I can't see how libvirt can do any better than qemu/kvm is doing
> already.  So unless someone comes along with an argument that using
> (eg) hpet is better for Windows guests or something, then I suggest
> that libvirt doesn't need to do anything.

Ok, agreed. I'll bring the issue up once there's a real benefit of
having this configurable.

Cheers,
Tiziano



-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail     : dev-zero@xxxxxxxxxx
GnuPG FP   : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]