On Fri, May 20, 2011 at 12:47 PM, Steve Kemp <steve@xxxxxxxxxxxxxx> wrote: > On Fri May 20, 2011 at 12:01:58 +0100, Stefan Hajnoczi wrote: > >> > wget http://mirror.bytemark.co.uk/misc/test-files/500M >> > while true; do cp 500M foo.img; rm foo.img; sleep 2; done >> > >> > "top" shows the virt memory growing to >1gb in under two minutes. >> >> Were you able to track down the culprit? > > Yes, or at least confirm my suspicion. The virtio block device > is the source of the leak. > > Host kernel: 2.6.32.15 > Guest Kernel: linux-2.6.32.23 > > Leaking case: > > opt/kvm2/bin/qemu-system-x86_64 -m 500 \ > -drive file=/machines/kvm2/jail/root_fs,if=virtio,cache=off > > Non leaking case: > > /opt/kvm/current/bin/qemu-system-x86_64 -m 500 \ > -drive file=/machines/kvm1/jail/root_fs,cache=off .. > > The leak occurs with both KVM 0.12.5 and 0.14.0. > > I've had a quick read of hw/virtio-blk.c but didn't see anything > glaringly obvious. I'll need to trace through the code, drink more > coffee, or get lucky to narrow it down further. Enabling the memory allocation trace events and adding the __builtin_return_address() to them should provide enough information to catch the caller who is leaking memory. Stefan -- 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
