| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: super page with live migration
Just realize that superpage may extend the service shutdown
time in migration process. Take a ideal convergence example for non-super page
cases, just dozens of pages may keep dirty at last batch sent to target side,
and thus service shutdown phase is short. However when superpage is enabled,
it's possible that those dozens of dirty
pages are multiplied with a 512 factor for an extreme case where each
page comes from different 2M super page. Then service shutdown phase can be
longer, though not measured. Not sure how
such inefficiency can be optimized...
Thanks,
Kevin
Yes, quite apart from anything else, you’re just
punting the problem of detecting superpages (or candidates for superpages) to
the sender. I’m pretty confident it won’t be slow and, for a live migration,
the superpage logic in the restore logic is only really going to get kicked in
the first batch (we could even add that as an extra condition) so won’t extend
‘dead time’ at all.
-- Keir
On 27/9/08 11:06, "Ian Pratt"
<Ian.Pratt@xxxxxxxxxxxxx> wrote:
I don't think the proposed logic is
particularly tricky, and it won't be slow - the initial test of looking for
the first page in a 2.MB extent acts as a good filter.
It will work
better than mmarking super pages on the
sender.
Ian
----- Original Message -----
From:
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
<xen-devel-bounces@xxxxxxxxxxxxxxxxxxx>
To: Keir Fraser
Cc:
xen-devel@xxxxxxxxxxxxxxxxxxx <xen-devel@xxxxxxxxxxxxxxxxxxx>
Sent:
Sat Sep 27 10:19:15 2008
Subject: [Xen-devel] Re: super page with live
migration
Keir Fraser wrote:
> On 26/9/08 08:45, "Zhai, Edwin"
<edwin.zhai@xxxxxxxxx> wrote:
>
>
>> As
you know, we try to allocate super pages in xc_hvm_build for
better
>> performance in EPT case. But the same logic is missing in
xc_domain_restore.
>>
>> When try to add the logic, I
found it is blocked by the lazy populate
>> algorithm
>>
in restore -- only populating the pages received from source side rather
than
>> doing it at one time.
>>
>> So the result
is the EPT guest has performance drop after live
migration:(
>>
>> Do you have any plan to change the lazy
populate algorithm? The purpose of it,
>> I
>> believe, is
to make restore process work without guest memory layout
>>
knowledge.
>>
>
> Yes: If
pseudo-phys page is not yet populated in target domain, AND it is
>
first page of a 2MB extent, AND no other pages in that extent are
yet
> populated, AND the next pages in the save-image stream populate
that extent
> in order, THEN allocate a superpage. This is made
trickier by the fact that
> the next 511 pages (to make the 2MB
extent) might be split across a batch
> boundary. So we'll have to
optimistically allocate a superpage in that case,
> and then shatter
it if it turns out that the contiguous stream of
> pseudo-phys
addresses is broken in the next batch.
>
It's really
tricky logic, and may make the migration process longer:(
Maybe the
flag the start-of-a-superpage as Tim said can make it
easier.
Thanks,
> --
Keir
>
>
>
_______________________________________________
Xen-devel
mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home