[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: |
Dor Laor |
Subject: |
[Qemu-devel] RE: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2 |
Date: |
Wed, 22 Aug 2007 14:35:53 -0700 |
>> > >>> This is QEMU, with dynticks and HPET:
>> > >>>
>> > >>> % time seconds usecs/call calls errors syscall
>> > >>> ------ ----------- ----------- --------- ---------
-------------
>---
>> > >>> 52.10 0.002966 0 96840
clock_gettime
>> > >>> 19.50 0.001110 0 37050
timer_gettime
>> > >>> 10.66 0.000607 0 20086
timer_settime
>> > >>> 10.40 0.000592 0 8985 2539 sigreturn
>> > >>> 4.94 0.000281 0 8361 2485 select
>> > >>> 2.41 0.000137 0 8362 gettimeofday
>> > >>> ------ ----------- ----------- --------- ---------
-------------
>---
>> > >>> 100.00 0.005693 179684 5024 total
>> > >>>
>> > >>>
>> > >> This looks like 250 Hz?
>> > >>
>> > >
>> > > Nope:
>> > >
>> > > # CONFIG_NO_HZ is not set
>> > > # CONFIG_HZ_100 is not set
>> > > # CONFIG_HZ_250 is not set
>> > > # CONFIG_HZ_300 is not set
>> > > CONFIG_HZ_1000=y
>> > > CONFIG_HZ=1000
>> > >
>> > > and I'm reading it from /proc/config.gz on the guest.
>> > >
>> >
>> > Yeah, thought so -- so dyntick is broken at present.
>>
>> I see a lot of sub ms timer_settime(). Many of them are the result of
>> ->expire_time being less than the current qemu_get_clock(). This
>> results into 250us timer due to MIN_TIMER_REARM_US; this happens only
>> for the REALTIME timer. Other sub-ms timers are generated by the
>> VIRTUAL timer.
>>
>> This first issue is easily fixed; if expire_time < current time then
>> the timer has expired and hasn't been reprogrammed (and thus can be
>> ignored).
>> VIRTUAL just becomes more accurate with dyntics, before multiple
>> timers were batched together.
>>
>> > Or maybe your host kernel can't support such a high rate.
>>
>> I don't know... a simple printf tells me that the signal handler is
>> called about 1050 times per second, which sounds about right.
>
>...unless strace is attached. ptrace()'ing the process really screw up
>the timing with dynticks; HPET is also affected but the performance
>hit is not as severe.
>
>Luca
I didn't figure out how you use both hpet and dyn-tick together.
Hpet has periodic timer while dyn-tick is one shot timer each time.
Is ther a chance that both are working and that's the source of our
problems?
Dor
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, (continued)
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca Tettamanti, 2007/08/21
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, malc, 2007/08/21
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Avi Kivity, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca Tettamanti, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Avi Kivity, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Avi Kivity, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca, 2007/08/22
- [Qemu-devel] RE: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2,
Dor Laor <=
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Luca, 2007/08/22
- [Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2, Dan Kenigsberg, 2007/08/22