All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Okken <James.Okken@dialogic.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvm-owner@vger.kernel.org" <kvm-owner@vger.kernel.org>
Subject: RE: CentOS 7.2 HVM, PVM and/or PVHVM
Date: Mon, 3 Apr 2017 17:22:55 +0000	[thread overview]
Message-ID: <MWHPR0101MB3072D0A8B0A249D7171946908D080@MWHPR0101MB3072.prod.exchangelabs.com> (raw)
In-Reply-To: <8dd6cf57-2444-ef07-492b-d02f3a08c080@redhat.com>

Sorry Paolo, it was my understanding inferred from other sources  that caused me to infer the wrong thing from what you said.
:)

Thank you for the advice. I will look into nohz_full in the host and the guest, as well as the Linux realtime patch

So may I infer from what you said that we can get better realtime performance by tweaking HVM VMs, both on KVM and XEN?


Thanks!

-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com] 
Sent: Monday, April 03, 2017 12:59 PM
To: James Okken; kvm@vger.kernel.org; kvm-owner@vger.kernel.org
Subject: Re: CentOS 7.2 HVM, PVM and/or PVHVM



On 03/04/2017 17:36, James Okken wrote:
> Thanks Paolo,
> 
> So are you saying that if I am running a very latency sensitive, 
> real-time, voice and video over IP application, then fundamentally KVM 
> is not the best way to go? I would be better off going with XEN?

No, I haven't said anything like that... Where did you infer it from? :)

In fact I said:

> the kernel knows it's running on KVM and is using some services from 
> the hypervisor to improve performance or functionality.
> [virtio] is just a set of PCI devices whose design was optimized for 
> virtualization

KVM has effectively all the benefits of paravirtualization while using standard PC hardware and firmware.  The same holds for Xen too, there is hardly any performance penalty from hardware emulation in HVM domains compared to PVH, and both Xen PVH and Xen HVM should be faster than Xen PV.

KVM is used often with DPDK and other latency sensitive applications.  I suggest you look into using nohz_full in the host and the guest, as well as the Linux realtime patch.

Thanks,

Paolo

  reply	other threads:[~2017-04-03 17:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 15:44 CentOS 7.2 HVM, PVM and/or PVHVM James Okken
2017-03-31 11:13 ` Paolo Bonzini
2017-03-31 21:20   ` James Okken
2017-04-02 19:39     ` Paolo Bonzini
2017-04-03 15:36       ` James Okken
2017-04-03 16:59         ` Paolo Bonzini
2017-04-03 17:22           ` James Okken [this message]
2017-04-03 17:26             ` Paolo Bonzini

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=MWHPR0101MB3072D0A8B0A249D7171946908D080@MWHPR0101MB3072.prod.exchangelabs.com \
    --to=james.okken@dialogic.com \
    --cc=kvm-owner@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /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.