qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Will the ELI incorporated in theKVM?


From: GaoYi
Subject: Re: [Qemu-devel] Will the ELI incorporated in theKVM?
Date: Thu, 20 Sep 2012 13:42:51 +0800

   The CPU isolation in Hitachi patches is just to improve the real time performance of GUEST. The core of it, direct IRQ delivery, is very similar to that of ELI.
    For the ELI patches,
    (1) Since EOI part of ELI is already supported by the Intel Sandy Bridge CPUs and requires modifications on GUEST code, it should not be included in the KVM. Only the ELI delivery part, which plays a vital role in performance improvement, should be considered.
    (2) It should be provided in the kvm-kmod or qemu-kvm ( not just for some linux kernel as Hitachi patches do), to make this part independent of linux kernel version.

Yi

2012/9/19 Jan Kiszka <address@hidden>
On 2012-09-19 16:43, Abel Gordon wrote:
>
>> It's imperfect as you need to dedicate a core to pure guest-mode load
>> and cannot run userspace on that core (cannot walk through
>> userspace-based device models e.g.).
>
> That's not correct.
> For the evaluation, we dedicated a core for each guest to maximize the
> performance but this
> is not a requirement. You can over-commit cores and share them across
> multiple VMs. In this case,
> you will be sharing the cycles among all the VMs and the performance per VM
> will be degraded.
> In addition, if you share a core, an interrupt for a guest may be raised
> while the corresponding
> VCPU is not running. Depending on the workload, most of the interrupts will
> be generated while
> the VCPU runs or not.
>
>> and cannot run userspace on that core (cannot walk through
>> userspace-based device models e.g.).
>
> That's not correct.
> We can run any thread (including user-space threads) on the same core we
> run the VMs (VCPU threads).
> In fact, we did that for the ELI evaluation: we shared a single core to run
> the VCPU thread and ALL the host threads (including qemu I/O thread).
>
>> And it requires that magic bar to
>> map the shadow IDT into the guest (hmm, I think Hitachi avoided this).
>
> Hitachi uses a different technique which seems to have the 2 disadvantages
> you previously mentioned while ELI doesn't have these disadvantages.
>
>> It's invasive as it has to change Linux to maintain those isolated slave
>> CPUs. That is, of course, based on code that was published by Hitachi.
>> Yours may differ but will still have to solve the same problems.
>
> ELI does not require isolated/slave CPUs.
>

OK. Show patches.

Jan

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]