All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beth Kon <eak@us.ibm.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC][PATCH] Add HPET emulation to qemu (v2)
Date: Tue, 12 Aug 2008 12:33:52 -0400	[thread overview]
Message-ID: <1218558832.7401.13.camel@beth-ubuntu> (raw)
In-Reply-To: <20080802172103.GH4535@implementation>

On Sat, 2008-08-02 at 18:21 +0100, Samuel Thibault wrote:
> Anthony Liguori, le Sat 02 Aug 2008 09:46:30 -0500, a écrit :
> > Samuel Thibault wrote:
> > >Beth Kon, le Sat 02 Aug 2008 06:05:14 -0500, a écrit :
> > >  
> > >>I was trying to reproduce the wakeup every 10ms that 
> > >>Samuel Thibault mentioned, thinking the HPET would improve it. 
> > >>But for an idle guest in both cases (with and without HPET), the 
> > >>number of wakeups per second was relatively low (28).
> > >>    
> > >
> > >I was referring to vl.c's timeout = 10; which makes the select call
> > >use a timeout of 10ms. That said, "/* If all cpus are halted then wait
> > >until the next IRQ */", so maybe that's why you get slower wakeups per
> > >second.  I'm still surprised because of the call to qemu_mod_timer in
> > >pit_irq_timer_update which should setup at least a 100Hz timer with
> > >linux guests (when they don't have HPET available).
> > >  
> > 
> > The patch disables that when hpet is active.
> 
> That's why I would expect, indeed, but he is reporting that _without_
> HPET he gets low wakeups per second already.
> 
> Samuel

Yes, 28 is incorrect. I was misinterpreting the output of powertop,
shown here:

Wakeups-from-idle per second : 27.7     interval: 10.0s
no ACPI power usage estimate available

Top causes for wakeups:
  46.1% ( 63.9)   qemu-system-x86 : schedule_timeout (process_timeout)
  36.5% ( 50.6)   qemu-system-x86 : sys_timer_settime (posix_timer_fn)
  ...


The "Wakeups-from-idle per second" reports 27.7, but the powertop source
code shows that this value is the total wakeups-per-second divided by
the number of online processors. So the proper number of
wakeups-per-second caused by the select is 63.9, which makes more
sense. 

Looking at the main_loop code, there is no way to get a timeout of
greater than 10 without setting icount. 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak@us.ibm.com


WARNING: multiple messages have this Message-ID (diff)
From: Beth Kon <eak@us.ibm.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC][PATCH] Add HPET emulation to qemu (v2)
Date: Tue, 12 Aug 2008 12:33:52 -0400	[thread overview]
Message-ID: <1218558832.7401.13.camel@beth-ubuntu> (raw)
In-Reply-To: <20080802172103.GH4535@implementation>

On Sat, 2008-08-02 at 18:21 +0100, Samuel Thibault wrote:
> Anthony Liguori, le Sat 02 Aug 2008 09:46:30 -0500, a écrit :
> > Samuel Thibault wrote:
> > >Beth Kon, le Sat 02 Aug 2008 06:05:14 -0500, a écrit :
> > >  
> > >>I was trying to reproduce the wakeup every 10ms that 
> > >>Samuel Thibault mentioned, thinking the HPET would improve it. 
> > >>But for an idle guest in both cases (with and without HPET), the 
> > >>number of wakeups per second was relatively low (28).
> > >>    
> > >
> > >I was referring to vl.c's timeout = 10; which makes the select call
> > >use a timeout of 10ms. That said, "/* If all cpus are halted then wait
> > >until the next IRQ */", so maybe that's why you get slower wakeups per
> > >second.  I'm still surprised because of the call to qemu_mod_timer in
> > >pit_irq_timer_update which should setup at least a 100Hz timer with
> > >linux guests (when they don't have HPET available).
> > >  
> > 
> > The patch disables that when hpet is active.
> 
> That's why I would expect, indeed, but he is reporting that _without_
> HPET he gets low wakeups per second already.
> 
> Samuel

Yes, 28 is incorrect. I was misinterpreting the output of powertop,
shown here:

Wakeups-from-idle per second : 27.7     interval: 10.0s
no ACPI power usage estimate available

Top causes for wakeups:
  46.1% ( 63.9)   qemu-system-x86 : schedule_timeout (process_timeout)
  36.5% ( 50.6)   qemu-system-x86 : sys_timer_settime (posix_timer_fn)
  ...


The "Wakeups-from-idle per second" reports 27.7, but the powertop source
code shows that this value is the total wakeups-per-second divided by
the number of online processors. So the proper number of
wakeups-per-second caused by the select is 63.9, which makes more
sense. 

Looking at the main_loop code, there is no way to get a timeout of
greater than 10 without setting icount. 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak@us.ibm.com

  parent reply	other threads:[~2008-08-12 16:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-02 11:05 [RFC][PATCH] Add HPET emulation to qemu (v2) Beth Kon
2008-08-02 11:05 ` [Qemu-devel] " Beth Kon
2008-08-02 11:38 ` Samuel Thibault
2008-08-02 11:38   ` [Qemu-devel] " Samuel Thibault
2008-08-02 14:46   ` Anthony Liguori
2008-08-02 17:21     ` Samuel Thibault
2008-08-02 17:21       ` Samuel Thibault
2008-08-02 17:26       ` Samuel Thibault
2008-08-12 16:33       ` Beth Kon [this message]
2008-08-12 16:33         ` Beth Kon
2008-08-02 11:42 ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1218558832.7401.13.camel@beth-ubuntu \
    --to=eak@us.ibm.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=samuel.thibault@ens-lyon.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.