From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: .img on nfs, relative on ram, consuming mass ram Date: Thu, 16 Sep 2010 14:03:54 +0200 Message-ID: <4C9207AA.9070009@amd.com> References: <20100915113941.9536341d.f.tournier@iut.univ-paris8.fr> <4C91DEDD.9030508@amd.com> <20100916140139.e5c4a8fe.f.tournier@iut.univ-paris8.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "kvm@vger.kernel.org" To: =?UTF-8?B?VE9VUk5JRVIgRnLDqWTDqXJpYw==?= Return-path: Received: from tx2ehsobe002.messaging.microsoft.com ([65.55.88.12]:15764 "EHLO TX2EHSOBE003.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753461Ab0IPMJY convert rfc822-to-8bit (ORCPT ); Thu, 16 Sep 2010 08:09:24 -0400 In-Reply-To: <20100916140139.e5c4a8fe.f.tournier@iut.univ-paris8.fr> Sender: kvm-owner@vger.kernel.org List-ID: TOURNIER Fr=C3=A9d=C3=A9ric wrote: > Ok, thanks for taking time. > I'll dig into your answers. >=20 > So as i run relative.img on diskless systems with original.img on nfs= , what are the best practice/tips i can use ? I thinks it is "-snapshot" you are looking for. This will put the backing store into "normal" RAM, and you can later=20 commit it to the original image if needed. See the qemu manpage for mor= e=20 details. In a nutshell you just specify the original image and add=20 -snapshot to the command line. Regards, Andre. >=20 > Is ramfs more suitable than tmpfs ? >=20 > Fred. >=20 > On Thu, 16 Sep 2010 11:09:49 +0200 > Andre Przywara wrote: >=20 >> TOURNIER Fr=C3=A9d=C3=A9ric wrote: >>> Hi ! >>> Here's my config : >>> >>> Version : qemu-kvm-0.12.5, qemu-kvm-0.12.4 >>> Hosts : AMD 64X2, Phenom and Core 2 duo >>> OS : Slackware 64 13.0 >>> Kernel : 2.6.35.4 and many previous versions >>> >>> I use a PXE server to boot semi-diskless (swap partitions and some = local stuff) stations. >>> This server also serves a read-only nfs folder, with plenty of .img= on it. >>> When clients connects, a relative image is created in /tmp, which i= s a tmpfs, so hosted in ram. >>> >>> And here i go on my 2G stations : >>> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localti= me -soundhw es1370 /tmp/relimg.img >>> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localti= me -soundhw es1370 /dev/shm/relimg.img >>> >>> I tried both. Always the same result : the ram is consumed quickly,= and mass swap occurs. >> Which is only natural, as tmpfs is promising to never swap. So it wi= ll=20 >> take precedence over other RAM (that's why it is limited to half of = the=20 >> memory by default). As soon as the guest has (re)written more disk=20 >> sectors than your free RAM can hold, the system will start to swap o= ut=20 >> your guest RAM (and other host applications). >> So in general you should avoid putting relative disk images to tmpfs= if=20 >> your host memory is limited. As a workaround you could try to furthe= r=20 >> limit the tmpfs max size (mount -t tmpfs -o size=3D512M none /dev/sh= m),=20 >> but this could lead to data loss in your guest as it possibly cannot= =20 >> back the written sectors anymore. >>> On a 4G system, i see kvm uses more than 1024, maybe 1200. >>> And everytime a launch a program inside the vm, the amount of the h= ost free ram (not cached) diminishes, which is weird, because it should= have been reserved. >> KVM uses on-demand paging like other applications. So it will not=20 >> reserve memory for your guest (unless you use hugetlbfs's -mempath): >> $ kvm -cdrom ttylinux_ser.iso -nographic -m 3072M >> $ top >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAN= D=20 >> >> 6015 user 20 0 3205m 128m 3020 S 2 2.2 0:04.94 kvm=20 >> >> >> Regards, >> Andre. >> >>> So on a 2G system, swap occurs very fast and the machine slow a lot= down. >>> An on a total diskless system, this leads fast to a freeze. >>> >>> I have no problem if i use a relative image on disk : >>> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localti= me -soundhw es1370 -drive file=3D/mnt/hd/sda/sda1/tmp/relimg.img,cache=3D= none >> --=20 >> Andre Przywara >> AMD-Operating System Research Center (OSRC), Dresden, Germany >> Tel: +49 351 448-3567-12 >> >=20 --=20 Andre Przywara AMD-OSRC (Dresden) Tel: x29712