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

2007-08-20 Thread Luca
On 8/20/07, malc <[EMAIL PROTECTED]> wrote: > On Mon, 20 Aug 2007, Luca Tettamanti wrote: > > > Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto: > >> Luca wrote: > >>> On 8/19/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote: > >>> > +static uint64_t qemu_next_deadline(void) { > >

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

2007-08-20 Thread malc
On Mon, 20 Aug 2007, Luca Tettamanti wrote: > Il Sun, Aug 19, 2007 at 10:31:26PM +0300, Avi Kivity ha scritto: >> Luca wrote: >>> On 8/19/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote: >>> +static uint64_t qemu_next_deadline(void) { +uint64_t nearest_delta_us = ULLONG_MAX; +

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

2007-08-20 Thread Avi Kivity
Avi Kivity wrote: > Paul Brook wrote: >>> Yes, good thinking, but this should only be done if it actually impacts >>> something. Reducing overhead from 0.1% to 0.05% is not worthwhile >>> if it >>> introduces extra complexity. >>> >> >> >> If the overhead is that small, why are we touching t

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

2007-08-19 Thread Avi Kivity
Jamie Lokier wrote: > Paul Brook wrote: > >>> Yes, good thinking, but this should only be done if it actually impacts >>> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it >>> introduces extra complexity. >>> >> If the overhead is that small, why are we touching thi

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

2007-08-19 Thread Jamie Lokier
Paul Brook wrote: > > Yes, good thinking, but this should only be done if it actually impacts > > something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it > > introduces extra complexity. > > If the overhead is that small, why are we touching this code in the first > place? Insig

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

2007-08-19 Thread Dor Laor
>>> Yes, good thinking, but this should only be done if it actually >impacts >>> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if >it >>> introduces extra complexity. >>> >> >> >> If the overhead is that small, why are we touching this code in the >first >> place? >> > >Accurac

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

2007-08-19 Thread Avi Kivity
Paul Brook wrote: >> Yes, good thinking, but this should only be done if it actually impacts >> something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it >> introduces extra complexity. >> > > > If the overhead is that small, why are we touching this code in the first > place?

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

2007-08-19 Thread Paul Brook
> Yes, good thinking, but this should only be done if it actually impacts > something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it > introduces extra complexity. If the overhead is that small, why are we touching this code in the first place? Paul

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

2007-08-19 Thread Avi Kivity
Jamie Lokier wrote: > Avi Kivity wrote: > > In this case the dyn-tick minimum res will be 1msec. I believe it should > work ok since this is the case without any dyn-tick. > > Actually minimum resolution depends on host HZ setting, but - yes - essential

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

2007-08-19 Thread Jamie Lokier
Avi Kivity wrote: > >>>In this case the dyn-tick minimum res will be 1msec. I believe it should > >>>work ok since this is the case without any dyn-tick. > >>> > >>Actually minimum resolution depends on host HZ setting, but - yes - > >>essentially you have the same behaviour of the "unix" tim