public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Oscar Garcia <oscar@softlab.cs.tsukuba.ac.jp>,
	kvm@vger.kernel.org
Subject: Re: VMEXIT and Threads
Date: Mon, 06 Oct 2014 09:29:26 +0200	[thread overview]
Message-ID: <543244D6.1070901@siemens.com> (raw)
In-Reply-To: <54323BDE.6040309@redhat.com>

On 2014-10-06 08:51, Paolo Bonzini wrote:
> Il 06/10/2014 06:45, Oscar Garcia ha scritto:
>>
>> I have a host with debian 7 (intel i7 - RAM 8GB), the guest OS is also
>> debian. I am running a program with some threads, every thread makes a
>> vmexit call. Also every thread runs in a isolated vcpu. The problem is
>> that the program does not run fluently, it looks like that every thread
>> interfere with each other. This situation does not happen when
>> separately processes call vmexit simultaneously. The question is: there
>> is any restriction (any lock) that block the threads. I am not sure
>> maybe libc, RCU, on even Qemu and KVM?
> 
> At the KVM level, _most_ VCPU ioctls can run concurrently because they
> only take a VCPU-level mutex.
> 
> QEMU however will take a global mutex on each exit to userspace.  What
> vmexits are these?

Expensive is usually anything related to VGA emulation - as it may draw
synchronously. But also writing to the emulated serial port when that
one dumps to the host's console under X. If only one VCPU is stuck in
this, also if that is unrelated to you primary guest load, even a
trivial "kick NIC in order to send my packet" may have to wait for
milliseconds.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2014-10-06  7:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-06  4:45 VMEXIT and Threads Oscar Garcia
2014-10-06  6:51 ` Paolo Bonzini
2014-10-06  7:29   ` Jan Kiszka [this message]
2014-10-06 19:07 ` Marcelo Tosatti

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=543244D6.1070901@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=oscar@softlab.cs.tsukuba.ac.jp \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox