[Qemu-devel] IO performance difference on different kernels

[cauchy-love <cauchy-love@163.com>]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]


I am using qemu2.3.0 to start a guest on different linux kernel (2.6.33 and 2.6.39). The qemu command line is:
       kvm -m 2g -hda guest.img -enable-kvm
Experiments show that the disk write bandwidth of the guest on 2.6.33.3 is 10 times of that on 2.6.39. The period of paio_submit (time difference between two consecutive callbacks) on 2.6.39 is around 10 times of that on 2.6.33 but the time cost on aio_worker function does not show much difference between these two kernels. Hope you can provide some help on debug this problem. 
Yi



--
发自我的网易邮箱手机智能版


在 2015-06-28 15:43:36，"Jan Kiszka" <jan.kiszka@web.de> 写道：
>Hi David,
>
>On 2015-06-26 17:32, David kiarie wrote:
>> Hi all,
>> 
>> Some efforts to emulate AMD IOMMU have being going over the past few months.
>> 
>> In real hardware AMD IOMMU is implemented as a PCI function. When
>> emulating it in Qemu we want to allocate it MMIO space but real AMD
>> IOMMU manage to reserve memory without making a BAR request, probably
>> through a static address that's written by the device.(This is
>> something similar to what non-PCI bus devices do).Trying to reserve
>> memory via a BAR request results in address conflicts(in Linux) and
>> all other PCI devices reserve platform resources via BAR requests.
>
>The AMD IOMMU spec makes it even clearer:
>
>"3 Registers
>
>The IOMMU is configured and controlled via two sets of registers — one
>in the PCI configuration space and another set mapped in system address
>space. [...]
>
>3.1 PCI Resources
>
>[...] A PCI Function containing an IOMMU capability block does not
>include PCI BAR registers."
>
>> 
>> I would like to hear suggestions on how to reserve a memory region for
>> the device without making a BAR request.
>
>I see two approaches:
>
> - Let the IOMMU sit on two buses, PCI and system, i.e. become a PCI
>   and SysBus device at the same time - I suspect, though, that this
>   cannot be modeled with QOM right now.
>
> - Model the MMIO registers via the BAR interface but overwrite the
>   PCI config space so that no BAR becomes visible and make sure that
>   writes to the PCI command register cannot disable this region (which
>   would be the case with normal BARs). Hackish, but it seems feasible.
>
>Jan
>
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]