From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: VMEXIT and Threads Date: Mon, 06 Oct 2014 09:29:26 +0200 Message-ID: <543244D6.1070901@siemens.com> References: <54321E64.8070306@softlab.cs.tsukuba.ac.jp> <54323BDE.6040309@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Paolo Bonzini , Oscar Garcia , kvm@vger.kernel.org Return-path: Received: from thoth.sbs.de ([192.35.17.2]:52359 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973AbaJFH3i (ORCPT ); Mon, 6 Oct 2014 03:29:38 -0400 In-Reply-To: <54323BDE.6040309@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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