qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerhard Wiesinger <lists@wiesinger.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance
Date: Thu, 22 Apr 2010 08:04:19 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1004220757520.10066@bbs.intern> (raw)
In-Reply-To: <4BCF6699.2060201@redhat.com>

On Wed, 21 Apr 2010, Avi Kivity wrote:

> On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
>>>> I don't think changing VGA window is a problem because there are
>>>> 500.000-1Mio changes/s possible.
>>> 
>>> 1MB/s, 500k-1M changes/s.... Coincidence?  Is it taking a page fault
>>> or trap on every write?
>> 
>> 
>> To clarify:
>> Memory Performance writing to segmen A000 is about 1MB/st.
>
> That indicates a fault every write (assuming 8-16 bit writes).  If you're 
> using 256 color vga and not switching banks, this indicates a bug.
>

Yes, 256 color VGA and no bank switches involved.

>> Calling INT 10 set/get window function with different windows (e.g. 
>> toggling between window page 0 and 1) is about 500.000 to 1Mio function 
>> calls per second.
>
> That's suprisingly fast. I'd expect 100-200k/sec.
>

Sorry, I mixed up the numbers:
1.) QEMU-KVM: ~111k
2.) QEMU only: 500k-1Mio

> Please run kvm_stat and report output for both tests to confirm.
>

See below. 2nd column is per second statistic when running the test.

>> 
>> To get real good VGA performance both parameters should be:
>> About >50MB/s for writes to segment A000
>> ~500.000 bank switches per second.
>
> First should be doable easily, second is borderline.
>
>> I think this is very easy to distingish:
>> 1.) VGA Segment A000 is legacy and should be handled through QEMU and not 
>> through KVM (because it is much more faster). Also 16 color modes should be 
>> fast enough there.
>> 2.) All other flat PCI memory accesses should be handled through KVM (there 
>> is a specialized driver loaded for that PCI device in the non legacy OS).
>> 
>> Is that easily possible?
>
> No.  Code can run in either qemu or kvm, not both.  You can switch between 
> them based on access statistics (early versions of qemu-kvm did that, without 
> the statistics part), but this isn't trivial.

Hmmm. Ok, 2 different opinions about the memory write performance:
Easily or not possible?

Thnx for you help so far.

Ciao,
Gerhard

-- 
http://www.wiesinger.com/

-------------
kvm_stat
Please mount debugfs ('mount -t debugfs debugfs /sys/kernel/debug')
and ensure the kvm modules are loaded

lsmod|grep -i kvm
kvm_amd                38276  0
kvm                   162288  1 kvm_amd

mount|grep -i debug

=>
mount -t debugfs debugfs /sys/kernel/debug

int10perf: INT10h Performance tests:
kvm statistics
  efer_reload                  0       0
  exits                 37648629  456206
  fpu_reload             8512535  455983
  halt_exits                2084       0
  halt_wakeup               2047       0
  host_state_reload      8513213  456011
  hypercalls                   0       0
  insn_emulation        29182065       0
  insn_emulation_fail          0       0
  invlpg                       0       0
  io_exits               8386082  455975
  irq_exits                51713     214
  irq_injections           21797      36
  irq_window                   0       0
  largepages                   0       0
  mmio_exits              242781       0
  mmu_cache_miss             150       0
  mmu_flooded                  0       0
  mmu_pde_zapped               0       0
  mmu_pte_updated              0       0
  mmu_pte_write             8192       0
  mmu_recycled                 0       0
  mmu_shadow_zapped          151       0
  mmu_unsync                   0       0
  mmu_unsync_global            0       0
  nmi_injections               0       0
  nmi_window                   0       0
  pf_fixed                 16935       0
  pf_guest                     0       0
  remote_tlb_flush             2       0
  request_irq                  0       0
  request_nmi                  0       0
  signal_exits                 1       0
  tlb_flush                 2251       0

Running VGA memory tests in same VGA page in Video Mode VESA 101h:
kvm statistics

  efer_reload                  0       0
  exits                 18470836  554582
  fpu_reload             2147833    3469
  halt_exits                2083       0
  halt_wakeup               2047       0
  host_state_reload      2148186    3470
  hypercalls                   0       0
  insn_emulation         7688203  554244
  insn_emulation_fail          0       0
  invlpg                       0       0
  io_exits              10701583      18
  irq_exits                50781     321
  irq_injections           25251      18
  irq_window                   0       0
  largepages                   0       0
  mmio_exits              162847    3241
  mmu_cache_miss             154       0
  mmu_flooded                  0       0
  mmu_pde_zapped               0       0
  mmu_pte_updated              0       0
  mmu_pte_write             8192       0
  mmu_recycled                 0       0
  mmu_shadow_zapped          155       0
  mmu_unsync                   0       0
  mmu_unsync_global            0       0
  nmi_injections               0       0
  nmi_window                   0       0
  pf_fixed                 16936       0
  pf_guest                     0       0
  remote_tlb_flush             5       0
  request_irq                  0       0
  request_nmi                  0       0
  signal_exits                 1       0
  tlb_flush                  112       0

  reply	other threads:[~2010-04-22  6:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 19:14 [Qemu-devel] QEMU-KVM and video performance Gerhard Wiesinger
2010-04-21  8:59 ` [Qemu-devel] " Avi Kivity
2010-04-21 10:08   ` Jamie Lokier
2010-04-21 10:49     ` Avi Kivity
2010-04-21 18:14       ` Gerhard Wiesinger
2010-04-21 20:49         ` Avi Kivity
2010-04-22  5:37           ` Gerhard Wiesinger
2010-04-22  6:57             ` Avi Kivity
2010-04-21 18:39       ` Jamie Lokier
2010-04-21 20:51         ` Avi Kivity
2010-04-21 21:19           ` Jamie Lokier
2010-04-22  5:44           ` Gerhard Wiesinger
2010-05-12 10:34             ` Jamie Lokier
2010-04-21 18:09   ` Gerhard Wiesinger
2010-04-21 18:33     ` Jamie Lokier
2010-04-21 18:50       ` Gerhard Wiesinger
2010-04-21 18:53         ` Jamie Lokier
2010-04-21 19:08           ` Gerhard Wiesinger
2010-04-21 21:30             ` Jamie Lokier
2010-04-22  6:12               ` Gerhard Wiesinger
2010-05-12 10:23                 ` Jamie Lokier
2010-04-21 20:56         ` Avi Kivity
2010-04-22  6:04           ` Gerhard Wiesinger [this message]
2010-04-22  7:03             ` Avi Kivity
2010-05-09 19:35               ` Gerhard Wiesinger
2010-05-10  7:32                 ` Avi Kivity
2010-05-12  6:14                   ` Gerhard Wiesinger
2010-05-12  6:39                     ` Avi Kivity
2011-02-18  7:32                       ` [Qemu-devel] Re: QEMU-KVM and video performance - Update Gerhard Wiesinger

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=alpine.LFD.2.00.1004220757520.10066@bbs.intern \
    --to=lists@wiesinger.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).