All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: "TOURNIER Frédéric" <f.tournier@iut.univ-paris8.fr>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: .img on nfs, relative on ram, consuming mass ram
Date: Mon, 20 Sep 2010 16:00:53 +0200	[thread overview]
Message-ID: <4C976915.5010305@amd.com> (raw)
In-Reply-To: <20100920153058.224f5038.f.tournier@iut.univ-paris8.fr>

TOURNIER Frédéric wrote:
> Heres my benches, done in two days so dates are weird and results are very approximative.
> What surprises me are in the Part 2, swap occured.
I don't know exactly why, but I have seen a small usage of swap 
occasionally without real memory pressure. So I'd consider this normal.

> In 3 and 4, the ram is eaten up, even if the vm just booted.
Where is the RAM eaten up? I see always always 800 MB free, some more 
even after the d/l:
You have to look at the second line of the free column, no the first 
one. As you can see the OS has still enough RAM to afford a large cache, 
so it uses this. Unused RAM is just a waste of resources (because it is 
always there and there is no reason to not use it). If the 'cached' 
contains a lot of clean pages, the OS can simply claim them should an 
application request more memory. If you want a proof of this, try:
# echo 3 > /proc/sys/vm/drop_caches
This should free the cache and give you a high "real" free value back.

Have you tried cache=none with the tmpfs scenario? That should save you 
some of the host's cached memory (note the difference between part 1 and 
part2 in that respect), maybe at the expense of the guest's memory used 
more heavily. Your choice here, that depends on the actual memory 
utilization in the guest.

As I said before, it is not a very good idea to use such a setup (with 
the relative image on tmpfs) if you are doing actual disk I/O, 
especially large writes. AFAIK QCOW[2] does not really shrink, it only 
grows, so you will end up with out-of-memory at some point.
But if you can restrict the amount of written data, this may work.

Regards,
Andre.

P.S. Sorry for the confusion about tmpfs vs. ramfs in my last week's mail.

> 
> ------------------------------------
> Part 0
> 
> End of boot :
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840     500836    1556004          0       2244     359504
> -/+ buffers/cache:     139088    1917752
> Swap:      3903784          0    3903784
> 
> ------------------------------------
> 
> Part 1
> 
> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 -name qlio -drive file=/mnt/hd/sda/sda1/tmp/relqlio.img,cache=none
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    1656280     400560          0      34884     378332
> -/+ buffers/cache:    1243064     813776
> Swap:      3903784          0    3903784
> 
> bash-3.1$ ls -lsa /mnt/hd/sda/sda1/tmp/relqlio.img
> 58946 -rw-r--r-- 1 ftournier info 60424192 2010-09-16 17:49 /mnt/hd/sda/sda1/tmp/relqlio.img
> 
> 650M download inside the vm
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    1677648     379192          0      33860     397716
> -/+ buffers/cache:    1246072     810768
> Swap:      3903784          0    3903784
> 
> bash-3.1$ ls -lsa /mnt/hd/sda/sda1/tmp/relqlio.img
> 914564 -rw-r--r-- 1 ftournier info 935723008 2010-09-20 14:07 /mnt/hd/sda/sda1/tmp/relqlio.img
> 
> ------------------------------------
> 
> Part 2
> 
> reboot
> 
> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 -name qlio -drive file=/mnt/hd/sda/sda1/tmp/relqlio.img
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    2040172      16668          0      32952     758948
> -/+ buffers/cache:    1248272     808568
> Swap:      3903784          0    3903784
> 
> bash-3.1$ ls -lsa /mnt/hd/sda/sda1/tmp/relqlio.img
> 60739 -rw-r--r-- 1 ftournier info 62259200 2010-09-16 17:57 /mnt/hd/sda/sda1/tmp/relqlio.img
> 
> 650M download inside the vm
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    2040540      16300          0      34412     765208
> -/+ buffers/cache:    1240920     815920
> Swap:      3903784       8160    3895624
> 
> bash-3.1$ ls -lsa /mnt/hd/sda/sda1/tmp/relqlio.img
> 842430 -rw-r--r-- 1 ftournier info 861929472 2010-09-20 14:20 /mnt/hd/sda/sda1/tmp/relqlio.img
> 
> ------------------------------------
> 
> Part 3
> 
> reboot
> 
> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 -name qlio -drive file=/tmp/relqlio.img
> 
> note : /tmp is a tmpfs filesystem
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    2009688      47152          0        248     766328
> -/+ buffers/cache:    1243112     813728
> Swap:      3903784          0    3903784
> 
> bash-3.1$ ls -lsa /tmp/relqlio.img
> 59848 -rw-r--r-- 1 ftournier info 61407232 2010-09-16 18:04 /tmp/relqlio.img
> 
> 650M download inside the vm
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    2041404      15436          0        128     921276
> -/+ buffers/cache:    1120000     936840
> Swap:      3903784     248804    3654980
> 
> bash-3.1$ ls -lsa /tmp/relqlio.img
> 885448 -rw-r--r-- 1 ftournier info 906821632 2010-09-20 14:40 /tmp/relqlio.img
> 
> ------------------------------------
> 
> Part 4
> 
> reboot
> 
> qemu-system-x86_64 -m 1024 -vga std -usb -usbdevice tablet -localtime -soundhw es1370 -name qlio -drive file=/dev/shm/relqlio.img
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    2009980      46860          0        172     767328
> -/+ buffers/cache:    1242480     814360
> Swap:      3903784          0    3903784
> 
> bash-3.1$ ls -lsa /dev/shm/relqlio.img
> 58496 -rw-r--r-- 1 ftournier info 59899904 2010-09-16 18:11 /dev/shm/relqlio.img
> 
> 650M download inside the vm
> 
> bash-3.1$ free
>              total       used       free     shared    buffers     cached
> Mem:       2056840    2041576      15264          0         92     938976
> -/+ buffers/cache:    1102508     954332
> Swap:      3903784     266232    3637552
> 
> bash-3.1$ ls -lsa /dev/shm/relqlio.img
> 1016912 -rw-r--r-- 1 ftournier info 1039400960 2010-09-20 15:15 /dev/shm/relqlio.img
> 


-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712


  reply	other threads:[~2010-09-20 14:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15  9:39 .img on nfs, relative on ram, consuming mass ram TOURNIER Frédéric
2010-09-16  9:09 ` Andre Przywara
2010-09-16 12:01   ` TOURNIER Frédéric
2010-09-16 12:03     ` Andre Przywara
2010-09-16 13:19       ` Stefan Hajnoczi
2010-09-16 13:48         ` Andre Przywara
2010-09-16 15:59           ` TOURNIER Frédéric
2010-09-20 13:30           ` TOURNIER Frédéric
2010-09-20 14:00             ` Andre Przywara [this message]
2010-09-20 15:34               ` TOURNIER Frédéric
2010-09-16 14:49   ` David S. Ahern
2011-09-19 12:12 ` Rickard Lundin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C976915.5010305@amd.com \
    --to=andre.przywara@amd.com \
    --cc=f.tournier@iut.univ-paris8.fr \
    --cc=kvm@vger.kernel.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.