Re: [Xen-devel] [PATCH] use INT64_MAX as max expiration

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 14 Mar 2012, Jan Beulich wrote:
> >>> On 14.03.12 at 03:54, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> > Currently, the max expiration time is 2147483647ns(INT32_MAX ns). This is 
> > enough when guest is busy, but when guest is idle, the next timer will be 
> > later than INT32_MAX ns. And those meaningless alarm will harm the pkg 
> > C-state.
> 
> A wakeup every 2s can't be that harmful.

Right, but it is still a very good idea to avoid it if we can


> > Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
> > ---
> >  vl.c |    6 +++---
> >  1 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/vl.c b/vl.c
> > index be8587a..40486eb 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -1410,8 +1410,8 @@ static int64_t qemu_next_deadline(void)
> >          delta = active_timers[QEMU_TIMER_VIRTUAL]->expire_time -
> >                       qemu_get_clock(vm_clock);
> >      } else {
> > -        /* To avoid problems with overflow limit this to 2^32.  */
> > -        delta = INT32_MAX;
> > +        /* To avoid problems with overflow limit this to 2^64 - 1000.  */
> > +        delta = INT64_MAX - 1000;
> 
> This looks rather arbitrary.

Give a look at qemu_next_deadline_dyntick, it adds 999 to whatever
qemu_next_deadline returns.

I think we should set delta to INT64_MAX in qemu_next_deadline and fix
the calculation of delta in qemu_next_deadline_dyntick so that it
doesn't overflow even if qemu_next_deadline returns INT64_MAX.
Something like:

delta = qemu_next_deadline();
delta = (delta / 1000) + (delta % 1000 > 0 ? 1 : 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel