Bug 704081 - mouse responds very slowly with huge memory
mouse responds very slowly with huge memory
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.7
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Marcelo Tosatti
Virtualization Bugs
: Reopened
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2011-05-12 01:55 EDT by Mike Cao
Modified: 2013-01-09 18:52 EST (History)
10 users (show)

See Also:
Fixed In Version: kvm-83-240.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-20 22:14:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
report.txt file (7.55 KB, text/plain)
2011-06-01 03:13 EDT, FuXiangChun
no flags Details

  None (edit)
Description Mike Cao 2011-05-12 01:55:50 EDT
Description of problem:
start VM with -m 256G ,mouse of guest responds very slowly.

Version-Release number of selected component (if applicable):
2.6.18-260.el5
# rpm -q kvm
kvm-83-232.el5
guest:
RHEL6.1_64 bit
How reproducible:
100%

Steps to Reproduce:
1.start vm with -m 256G
eg:/usr/libexec/qemu-kvm -M rhel5.6.0 -m 256G -smp 16,sockets=16,cores=1,threads=1 -name VM -uuid 502ae056-69fc-4039-b5e8-c9d4918e4a7d -monitor stdio -no-kvm-pit-reinjection -usbdevice tablet -startdate now -boot dc -drive file=/home/test.img,if=virtio,format=qcow2,werror=stop,cache=none,boot=on -net nic,macaddr=54:52:40:20:4c:58,vlan=0,model=virtio -net tap,script=/etc/qemu-ifup,downscript=no,vlan=0 -usb -vnc :3 -k en-us -balloon virtio -notify all -no-hpet -soundhw ac97

  
Actual results:
the mouse of guest responds very slowly

Expected results:


Additional info:
Tried same image with -smp=2 -m=2G ,guest works fine.
Comment 1 Mike Cao 2011-05-12 02:27:12 EDT
host info
# free -g
             total       used       free     shared    buffers     cached
Mem:           504        263        240          0          0          4
-/+ buffers/cache:        258        245
Swap:           33          0         33

#cat /proc/cpuinfo
processor       : 63
vendor_id       : GenuineIntel
cpu family      : 6
model           : 46
model name      : Intel(R) Xeon(R) CPU           X7550  @ 2.00GHz
stepping        : 6
cpu MHz         : 1995.043
cache size      : 18432 KB
physical id     : 3
siblings        : 16
core id         : 11
cpu cores       : 8
apicid          : 119
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc ida nonstop_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 sse4_2 popcnt lahf_lm
bogomips        : 3990.06
clflush size    : 64
cache_alignment : 64
address sizes   : 44 bits physical, 48 bits virtual
power management: [8]
Comment 2 Glauber Costa 2011-05-16 09:54:06 EDT
This host does not seem to have nested page tables. Maybe we're stuck at shadow page handling for too long, and lose interrupts ?
Comment 3 juzhang 2011-05-24 01:47:56 EDT
(In reply to comment #2)
> This host does not seem to have nested page tables. Maybe we're stuck at shadow
> page handling for too long, and lose interrupts ?
This host based on intel platform(Nehalem-EX) which support Extended Page Tables (EPT).

---snip form According to http://en.wikipedia.org/wiki/Extended_Page_Table--
Intel states that the feature is available in all their Nehalem-based CPUs with virtualization support.

Nested page tables(npt),seems amd named npt or Rapid Virtualization Indexing (RVI) .

I also tested on amd platform which support Nested page tables(npt),hit the same issue.



Host infos:
processor : 46
vendor_id : AuthenticAMD
cpu family : 16
model  : 9
model name : AMD Opteron(tm) Processor 6172
Comment 4 Marcelo Tosatti 2011-05-24 07:01:41 EDT
Is it reproducible with RHEL6.1 ?
Comment 5 Mike Cao 2011-05-25 02:09:51 EDT
(In reply to comment #4)
> Is it reproducible with RHEL6.1 ?

you mean RHEL6.1 guest or host ? the machine is reserved by others this week ,
will reply it in next week.

Best Regards,
mike
Comment 6 Marcelo Tosatti 2011-05-25 14:44:08 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Is it reproducible with RHEL6.1 ?
> 
> you mean RHEL6.1 guest or host ? the machine is reserved by others this week ,
> will reply it in next week.
> 
> Best Regards,
> mike

RHEL6.1 host. Once you have the guest running, please gather profiling information with:

# perf record -p $pid_of_qemu_kvm_process
 
move mouse for a few seconds in the guest

ctrl + c

# perf report --stdio > report.txt

And attach report.txt to this BZ.

Thanks
Comment 7 FuXiangChun 2011-06-01 03:13:10 EDT
Created attachment 502177 [details]
report.txt file
Comment 8 FuXiangChun 2011-06-01 03:16:40 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Is it reproducible with RHEL6.1 ?
> > 
> > you mean RHEL6.1 guest or host ? the machine is reserved by others this week ,
> > will reply it in next week.
> > 
> > Best Regards,
> > mike
> 
> RHEL6.1 host. Once you have the guest running, please gather profiling
> information with:
> 
> # perf record -p $pid_of_qemu_kvm_process
> 
> move mouse for a few seconds in the guest
> 
> ctrl + c
> 
> # perf report --stdio > report.txt
> 
> And attach report.txt to this BZ.
> 
> Thanks

this bug can not be reproduced on rhel6.1 host. report.txt file is in attachment

steps:
1. start rhel5.7 guest with 400G memory on rhel6.1 host
/usr/libexec/qemu-kvm -M rhel6.1.0 -enable-kvm -name rhel5.7 -smp 16 -m 400G -uuid 9e6f04cf-2ad7-45aa-9333-2d2ee26570c6 -boot c -drive file=/mnt/images/rhel57-64.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,boot=on,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:19:3b:80 -monitor stdio -vga cirrus -vnc :1

2.mount -t debugfs none /sys/kernel/debug
3.echo 1 >/sys/kernel/debug/tracing/events/kvm/enable
4.perf record -p $pid_of_qemu_kvm_process
5.move mouse for a few seconds in the guest
6.perf report --stdio > report.txt
Comment 9 Marcelo Tosatti 2011-06-06 14:43:35 EDT
FuXiangChun, Mike,

Since it is not reproducible on RHEL6.1, i'm closing the bug as CLOSED CURRENTRELEASE.
Comment 12 Mike Cao 2011-07-28 12:49:59 EDT
fuxiangchun,

pls arrange a big machine with latest RHEL5 tree and pre-install windows/linux guest for developer 

Thanks ,
Mike
Comment 18 FuXiangChun 2011-12-14 22:34:41 EST
1.reproduce with kvm-83-238.el5

steps to reproduce

1.1. /usr/libexec/qemu-kvm -M rhel5.6.0 -m 500G -smp 16,sockets=16,cores=1,threads=1 -name VM -uuid 502ae056-69fc-4039-b5e8-c9d4918e4a7d -monitor stdio -no-kvm-pit-reinjection -usbdevice tablet -startdate now -boot dc -drive file=/home/qcow2/RHEL-Server-6.2-64.qcow2,if=virtio,format=qcow2,werror=stop,cache=none,boot=on -net nic,macaddr=54:52:40:20:4c:58,vlan=0,model=virtio -net tap,script=/etc/qemu-ifup,downscript=no,vlan=0 -usb -vnc :3 -k en-us -balloon virtio -notify all -no-hpet -soundhw ac97

1.2. test mouse in guest

actual result:
  mouse responds very slowly

2.verify with kvm-83-246.el5
 2.1) repeat 1.1 command line
 2.2) repeat 1.2 process

actual result:
 mouse work well

base on above testing result, this bug is fixed.


additional info:
cat /proc/cpuinfo
model name	: AMD Opteron(tm) Processor 6172
Comment 20 errata-xmlrpc 2012-02-20 22:14:39 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0149.html

Note You need to log in before you can comment on or make changes to this bug.