HI Tomoki, Thanks for you config file, but it is for linux-3.5-rc4, but the patches you posted to the community was based on linux-3.6 as described in the following link. http://thread.gmane.org/gmane.linux.kernel/1353803 I also tested the config file on linux-3.6, still can not work. Could you please provide me the detail about your setup, for example: - kernel version and config - the version and url of your patch - qemu command line - other info so that I can try and reproduce your benchmark :-). I think that your patch would be a good workaround on realtime and performance improvement with hardware which do not support apicv. BTW, I notice your benchmark result in your slides, which shows that the throughput of a 10Gbps NIC exceeds 10Gbps? How did that happen? My benchmark also shows a interesting data: the throughput of a pass- through device is higher than bare-mental sometime.(I use NetPIPE) Thanks a lot. Yang Minqiang > -----Original Message----- > From: Tomoki Sekiyama [mailto:tomoki.sekiyama@xxxxxxx] > Sent: Thursday, April 11, 2013 4:37 AM > To: Yangminqiang > Cc: kvm@xxxxxxxxxxxxxxx; Haofeng; Luohao (brian) > Subject: Re: KVM: kvm_set_slave_cpu: Invalid argument when trying direct > interrupt delivery > > Hi, > > > On 4/7/13 6:09 , "Yangminqiang" <yangminqiang@xxxxxxxxxx> wrote: > >Hi Tomoki, > > > >I offline the cpu2 and cpu3 on my machine and continue to try your patch. > > I run the vm without pass-through device for I only want to know the > >interrupt latency improvement.(Am I right?) > > This should be OK. > > >my qemu parameter: > >./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -cpu > >qemu64,+x2apic -no-kvm-pit -serial pty -nographic -drive > >file=/mnt/sdb/vms/testfc/testfc.qcow2,if=virtio,index=0,format=qcow2 > >-spice > >port=12000,addr=186.100.8.171,disable-ticketing,plaintext-channel=main, > >pla > >intext-channel=playback,plaintext-channel=record,image-compression=aut > o > >_gl > >z -no-kvm-pit > > Using video (-spice) could cause a large latency, because non-passthrough > devices cause larger latency with this patch. > Please use serial console (but should avoid serial I/O while benchmark, > because serial I/O is also non-passthrough device). > > You may need to turn off CPU low power features, or running some infinite > loop (e.g. yes>/dev/null) to avoid cpu core from going into power saving > mode. > > > >cyclictest: > > cyclictest -m -p 99 -n -l 100000 -h 3000 -q > > > > > >but I got very bad result: > > avg lantency: 20000+ us > > max lantency: 50000+ us > > > >and got > > > >Message from syslogd@kvmsteven at Apr 7 05:43:30 ... > > kernel:[ 2201.151817] BUG: soft lockup - CPU#18 stuck for 22s! > >[qemu-system-x86:2365] > > This patch is not yet tested in various kernel CONFIG_* settings, and some > config may cause issue like this... > I was using Fedora-based config (attached). Could you try with this? > > >my setup: > >host kernel: 3.6.0-rc4+ and your patches guest kernel: 3.6.11.1-rt32 > >qemu: qemu-kvm-1.0 with your patch > > > >BTW, I am sure that my rt-kernel works well, which got 12us max latency > >as a host OS. > > > >Could you please provoide me more detail about your benchmark so I > >could reproduce your benchmark result? > > > >Thanks, > >Steven ��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
