* Leszek Urbanski <tygrys@xxxxxx> [2010-04-20 17:37]: > Hi, > > this is a follow-up to bug 2989366: > > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2989366&group_id=180599 > > after extensive debugging with the guys on #kvm it turns out that the leak is > in the qemu-kvm userland process, in virtio-blk. > > A summary of my setup is described in the bug report above. > > The affected guests have a common load profile: frequent sequential I/O on > large (~ 2 GB) files. > > I tried switching off or changing almost all options in my qemu command > line and the only option that makes a difference is -drive if=virtio. > > When an affected guest is run with virtio drives the qemu-kvm process starts > leaking immediately after startup and grows (for the most heavily leaking > guests) by ~ 1 GB RSS for every ten hours (and keeps growing until OOM). > > With -drive if=ide or scsi, it doesn't leak at all. > > A diff of /proc/<pid>/maps of an affected qemu-kvm at startup and after > 1.5 hrs: > > -039b9000-5ccd0000 rw-p 00000000 00:00 0 > +039b9000-65803000 rw-p 00000000 00:00 0 > > (a heap leak?) > > I'm willing to debug further. The problem is 100% reproducible. Is that qemu-kvm 0.12.3 compiled from source? or using the distro package? If you drop the -smp 4 part, you could also try plain qemu to eliminate if there was a qemu-kvm merge issue. Also, if you switch to a different guest do you still see the same leak? This should help determine if the virtio-blk front end is part of the issue. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
