|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH] virtio: Use ioeventfd for virtqueue notify |
Date: | Tue, 05 Oct 2010 13:58:44 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4 |
On 10/05/2010 01:00 PM, rukhsana ansari wrote:
Hi, W.r.t: > Note that this is a tradeoff. If an idle core is available and the > scheduler places the iothread on that core, then the heavyweight exit is > replaced by a lightweight exit + IPI. If the iothread is co-located with > the vcpu, then we'll take a heavyweight exit in any case. > Q: Does the kvm kernel code check for such a condition and take a heavyweight exit?
No. The heavyweight exit is caused by a context switch (partial) or return to userspace (full).
> The first case is very likely if the host cpu is undercommitted and there is > heavy I/O activity. This is a typical subsystem benchmark scenario (as > opposed to a system benchmark like specvirt). My feeling is that total > system throughput will be decreased unless the scheduler is clever enough to > place the iothread and vcpu on the same host cpu when the system is > overcommitted. > > Q: Sorry if the answer is obvious here. If the heavyweight exit is taken when both threads are assigned to the same core, how will the system throughput increase?
Co-locating threads on the same core reduces cross-core traffic. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |