Re: [PATCH 0/4] Rework alarm timer infrastrucure - take2

Luca
2007-08-22T22:07:37Z

On 8/22/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >> > >>> 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.
> >
> I didn't figure out how you use both hpet and dyn-tick together.

I don't. Only one timer source is active at any time; the selection is
done at startup with -clock option.

> 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?

No, the various sources are exclusive (though it might be possible to
use HPET in one shot mode).

Luca