From: "Zhai, Edwin" <edwin.zhai@intel.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: revisit the super page support in HVM restore
Date: Wed, 19 Aug 2009 15:55:55 +0800 [thread overview]
Message-ID: <4A8BB00B.6050000@intel.com> (raw)
In-Reply-To: <C6B1685E.1252C%keir.fraser@eu.citrix.com>
Keir Fraser wrote:
> On 19/08/2009 08:08, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:
>
>
>> So how about this new method:
>> * Not tracking each of pfn inside 2M page, but trying best to allocate
>> 2M pages if the 2M page covering this pfn is not allocated.
>> * There may be holes inside new allocated 2M pages that are not synced in
>> this batch, but we don't care and assume these missing pfns will
>> come in future.
>>
>> This new method is simple as the super page support for PV guest is
>> already there.
>>
>
> You wil fail to restore a guest which has ballooned down its memory as there
> will be 4k holes in its memory map.
I see. But current PV guest has same issue also. If set superpages for
the PV guest, allocate_mfn in xc_domain_restore.c would try to allocate
2M page for each of pfn regardless of the holes. Per my understanding,
this is more serious issue for PV guest, as it uses balloon driver more
frequently.
If we have to use this algorithm, back to my complicated code -- do you
have any suggestion to simplify the logic?
Thanks,
> You will allocate 2MB superpages despite
> these holes, which do not get fixed up until end of restore process, and run
> out of memory in the host, or against the guest's maxmem limit.
>
> -- Keir
>
>
>
--
best rgds,
edwin
next prev parent reply other threads:[~2009-08-19 7:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 7:08 revisit the super page support in HVM restore Zhai, Edwin
2009-08-19 7:29 ` Keir Fraser
2009-08-19 7:55 ` Zhai, Edwin [this message]
2009-08-19 9:04 ` Keir Fraser
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=4A8BB00B.6050000@intel.com \
--to=edwin.zhai@intel.com \
--cc=keir.fraser@eu.citrix.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.