All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: Joshua West <jwest@brandeis.edu>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Kurt C. Hackel" <kurt.hackel@oracle.com>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	James Harper <james.harper@bendigoit.com.au>,
	"wayne.gong@oracle.com" <wayne.gong@oracle.com>
Subject: Re: Error restoring DomU when using GPLPV
Date: Tue, 15 Sep 2009 15:27:59 -0700	[thread overview]
Message-ID: <4AB014EF.1050601@oracle.com> (raw)
In-Reply-To: <C6D5C5E1.14CE2%keir.fraser@eu.citrix.com>



Keir Fraser wrote:
> On 15/09/2009 22:25, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:
> 
>> No, it doesn't. I agree that after the first migration tot_pages will have
>> increased to 0x83ed. But I do not agree that it will continue to increase by
>> three pages on each future migration. Look at it this way -- three GPFNs
>> (guest-physical pages) have changed from xenheap pages to domheap pages
>> across that first migration. On future migrations they will be migrated just
>> like any other ordinary domheap page, since that's what they now are. And
>> tot_pages will therefore not change. Right?
> 
> Actually of course you do the right thing with the shinfo page, so actually
> one page per migration does get switched back to being a Xenheap page (the
> shinfo page) and tot_pages actually increases by 3 on the first migration,
> then decreases by 1 when shinfo gets remapped by the PV drivers. Then
> increases by 1 on every future migration (which is the shinfo Xenheap page
> getting changed into a domheap page), and then decreases by 1 when shinfo
> gets remapped by the PV drivers.
> 
> But even setting things out exactly right as above, the end result is the
> same: I *still* cannot explain Annie's result.

The bug in her driver is that its only remapping shinfo page, and NOT
the 2 shared grant frames. tot_pages hence increases by 2 every
migration. I can see all in kdb.  tot_pages goes up by 3, then down by 1
as shared info frame is remapped, and remains there. Next migration, it
goes up by 3, down by 1 again.  So each migration leaks 2 frames. The initial
difference is 21 frames between tot and max, hence after 10 migrations
it fails. (BTW, no max_mem specified in config file, I'm told it means no POD).

On linux side, driver remaps shinfo page + both grant frames. So, it goes up
by 3 for a moment, then comes remap and down by 3, back to where it was. If
tot_pages == max_pages, then mig will fail. Which brings me to a question,
to test out balloon changes, what would be the best way to get tot_pages
equal to max_pages. xm mem-set doesn't quite get me there. Occassionally
I see the two same after starting guest, but I've not figured out what
causes that to happen.

thakns
Mukesh



>  -- Keir
> 
>> This is why I still cannot understand or explain Annie's experimental
>> result.
> 

  reply	other threads:[~2009-09-15 22:27 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-04  1:22 Error restoring DomU when using GPLPV James Harper
2009-08-04  1:41 ` James Harper
2009-08-04  5:30   ` James Harper
2009-08-04  6:10     ` James Harper
2009-08-04  7:58       ` James Harper
2009-08-04  8:21         ` Keir Fraser
2009-08-04  9:01           ` James Harper
2009-08-04  9:27             ` Keir Fraser
2009-08-04  9:34               ` James Harper
2009-08-04 10:28                 ` Keir Fraser
2009-08-04 10:40                   ` James Harper
2009-08-04 11:02                     ` Keir Fraser
2009-08-04 11:34                       ` James Harper
2009-08-04 13:12                         ` Keir Fraser
2009-08-18  8:17                           ` Pasi Kärkkäinen
2009-08-18  9:33                             ` James Harper
2009-08-19  7:39                               ` ANNIE LI
2009-08-19  7:52                                 ` Keir Fraser
2009-08-20  3:21                                   ` ANNIE LI
2009-09-05  4:02                           ` Mukesh Rathor
2009-09-05  6:49                             ` Keir Fraser
2009-08-20  8:17                       ` ANNIE LI
2009-08-20  8:27                         ` Keir Fraser
2009-08-20  9:42                           ` James Harper
2009-08-20 10:05                             ` ANNIE LI
2009-08-20 10:20                               ` Keir Fraser
2009-08-20 11:55                               ` ANNIE LI
2009-08-20 12:28                                 ` Keir Fraser
2009-08-21  4:11                                   ` ANNIE LI
2009-08-26 11:04                                     ` ANNIE LI
2009-08-27  9:28                                       ` ANNIE LI
2009-08-28  3:10                                         ` ANNIE LI
2009-09-02  4:05                                           ` ANNIE LI
2009-09-02  4:27                                             ` ANNIE LI
2009-09-04 21:28                                               ` Dan Magenheimer
2009-09-04 23:02                                                 ` Dan Magenheimer
2009-09-05  6:52                                                   ` Keir Fraser
2009-09-05  7:33                                                     ` ANNIE LI
2009-09-15  2:25                                                     ` Mukesh Rathor
2009-09-15  7:39                                                       ` Keir Fraser
2009-09-15 19:14                                                         ` Mukesh Rathor
2009-09-15 21:25                                                           ` Keir Fraser
2009-09-15 21:29                                                             ` Keir Fraser
2009-09-15 22:27                                                               ` Mukesh Rathor [this message]
2009-09-16  4:37                                                               ` ANNIE LI
2009-09-16 11:10                                                                 ` ANNIE LI
2009-09-16 12:28                                                                   ` Keir Fraser
2009-09-16 18:09                                                                     ` Dan Magenheimer
2009-09-16 20:50                                                                       ` Mukesh Rathor
2009-09-17  6:21                                                                         ` Keir Fraser
2009-09-17 15:41                                                                           ` Dan Magenheimer
2009-09-24 20:24                                                                   ` Error restoring DomU when using GPLPV / fix for GPLPV drivers Pasi Kärkkäinen
2009-10-27 20:05                                                                     ` Keith Coleman
2009-08-20 10:19                             ` Error restoring DomU when using GPLPV Keir Fraser
2009-08-20 10:41                               ` Keir Fraser
2009-08-04 10:39               ` James Harper
2009-08-04  9:26           ` James Harper
2009-08-25 10:02             ` Wayne Gong

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=4AB014EF.1050601@oracle.com \
    --to=mukesh.rathor@oracle.com \
    --cc=annie.li@oracle.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=jwest@brandeis.edu \
    --cc=keir.fraser@eu.citrix.com \
    --cc=kurt.hackel@oracle.com \
    --cc=wayne.gong@oracle.com \
    --cc=xen-devel@lists.xensource.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.