[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] broken incoming migration

From: Peter Lieven
Subject: Re: [Qemu-devel] broken incoming migration
Date: Tue, 04 Jun 2013 16:48:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

On 04.06.2013 16:40, Paolo Bonzini wrote:
Il 04/06/2013 16:38, Peter Lieven ha scritto:
On 04.06.2013 16:14, Paolo Bonzini wrote:
Il 04/06/2013 15:52, Peter Lieven ha scritto:
On 30.05.2013 16:41, Paolo Bonzini wrote:
Il 30/05/2013 16:38, Peter Lieven ha scritto:
You could also scan the page for nonzero values before writing it.
i had this in mind, but then choosed the other approach.... turned
out to be a bad idea.

alexey: i will prepare a patch later today, could you then please
verify it fixes your problem.

paolo: would we still need the madvise or is it enough to not write
the zeroes?
It should be enough to not write them.
Problem: checking the pages for zero allocates them. even at the source.
It doesn't look like.  I tried this program and top doesn't show an
increasing amount of reserved memory:

#include <stdio.h>
#include <stdlib.h>
int main()
      char *x = malloc(500 << 20);
      int i, j;
      for (i = 0; i < 500; i += 10) {
          for (j = 0; j < 10 << 20; j += 4096) {
               *(volatile char*) (x + (i << 20) + j);
strange. we are talking about RSS size, right?
None of the three top values change, and only VIRT is >500 MB.

is the malloc above using mmapped memory?

which kernel version do you use?
Still using 3.2, but strange enough the above example is also not increasing 
RSS size for me.

Can you try the following:
qemu git master with 1G of memory (hanging in bios with no boot device) and 
migrate it. Before migration RSS Size os somewhat
around 16MB. After migration its RSS size is in the order of 1G.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]