[Top][All Lists]

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

[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucur

From: malc
Subject: [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2
Date: Tue, 21 Aug 2007 23:44:57 +0400 (MSD)

On Tue, 21 Aug 2007, Luca Tettamanti wrote:

Avi Kivity ha scritto:
Luca Tettamanti wrote:
At 1000Hz:

hpet            5.5%
dynticks       11.7%

hpet            3.4%
dynticks        7.3%

No surprises here, you can see the additional 1k syscalls per second.

This is very surprising to me.  The 6.2% difference for the qemu case
translates to 62ms per second, or 62us per tick at 1000Hz.  That's more
than a hundred simple syscalls on modern processors.  We shouldn't have to
issue a hundred syscalls per guest clock tick.

[..snip preulde..]

I've also tried APC which was suggested by malc[1] and:
- readings are far more stable
- the gap between dynticks and non-dynticks seems not significant

[..dont snip the obvious fact and snip the numbers..]

[1] copy_to_user inside spinlock is a big no-no ;)

[..notice a projectile targeting at you and rush to see the code..]

Mixed feelings about this... But in principle the code ofcourse is
dangerous, thank you kindly for pointing this out.

I see two ways out of this:

a. moving the lock/unlock inside the loop with unlock preceding
   sometimes sleep deprived copy_to_user

b. fill temporaries and after the loop is done copy it in one go

Too late, too hot, i wouldn't mind beying on a receiving side of
a good advice.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]