* VMEXIT and Threads
@ 2014-10-06 4:45 Oscar Garcia
2014-10-06 6:51 ` Paolo Bonzini
2014-10-06 19:07 ` Marcelo Tosatti
0 siblings, 2 replies; 4+ messages in thread
From: Oscar Garcia @ 2014-10-06 4:45 UTC (permalink / raw)
To: kvm
Hello,
I have a question about parallel vmexit calls, I would appreciate any
answer or suggestion.
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?
Thank you
Oscar Gracia
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: VMEXIT and Threads
2014-10-06 4:45 VMEXIT and Threads Oscar Garcia
@ 2014-10-06 6:51 ` Paolo Bonzini
2014-10-06 7:29 ` Jan Kiszka
2014-10-06 19:07 ` Marcelo Tosatti
1 sibling, 1 reply; 4+ messages in thread
From: Paolo Bonzini @ 2014-10-06 6:51 UTC (permalink / raw)
To: Oscar Garcia, kvm
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?
Paolo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: VMEXIT and Threads
2014-10-06 6:51 ` Paolo Bonzini
@ 2014-10-06 7:29 ` Jan Kiszka
0 siblings, 0 replies; 4+ messages in thread
From: Jan Kiszka @ 2014-10-06 7:29 UTC (permalink / raw)
To: Paolo Bonzini, Oscar Garcia, kvm
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: VMEXIT and Threads
2014-10-06 4:45 VMEXIT and Threads Oscar Garcia
2014-10-06 6:51 ` Paolo Bonzini
@ 2014-10-06 19:07 ` Marcelo Tosatti
1 sibling, 0 replies; 4+ messages in thread
From: Marcelo Tosatti @ 2014-10-06 19:07 UTC (permalink / raw)
To: Oscar Garcia; +Cc: kvm
On Mon, Oct 06, 2014 at 01:45:24PM +0900, Oscar Garcia wrote:
> Hello,
>
> I have a question about parallel vmexit calls, I would appreciate
> any answer or suggestion.
>
> 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.
How is that vmexit call made?
> 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.
Can you be more precise about this? Did you perform a measurement?
> 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?
In QEMU there is a mutex which is shared by all vcpus, and is acquired
right after entry in QEMU, named qemu_mutex.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-06 19:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-06 4:45 VMEXIT and Threads Oscar Garcia
2014-10-06 6:51 ` Paolo Bonzini
2014-10-06 7:29 ` Jan Kiszka
2014-10-06 19:07 ` Marcelo Tosatti
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.