On Wed, Apr 26, Andrew Cooper wrote:
> On 26/04/17 16:43, Olaf Hering wrote:
> > On Thu, Apr 20, Jan Beulich wrote:
> >
> > On 20.04.17 at 18:04, wrote:
> >>> On Thu, Apr 20, Andrew Cooper wrote:
> >>>
> As it currently stands, the sending side iterates from 0 to
On 26/04/17 16:43, Olaf Hering wrote:
> On Thu, Apr 20, Jan Beulich wrote:
>
> On 20.04.17 at 18:04, wrote:
>>> On Thu, Apr 20, Andrew Cooper wrote:
>>>
As it currently stands, the sending side iterates from 0 to p2m_size,
and sends every frame on the first pass.
On Thu, Apr 20, Jan Beulich wrote:
> >>> On 20.04.17 at 18:04, wrote:
> > On Thu, Apr 20, Andrew Cooper wrote:
> >
> >> As it currently stands, the sending side iterates from 0 to p2m_size,
> >> and sends every frame on the first pass. This means we get PAGE_DATA
> >> records
>>> On 20.04.17 at 18:04, wrote:
> On Thu, Apr 20, Andrew Cooper wrote:
>
>> As it currently stands, the sending side iterates from 0 to p2m_size,
>> and sends every frame on the first pass. This means we get PAGE_DATA
>> records linearly, in batches of 1024, or two aligned 2M
On Thu, Apr 20, Andrew Cooper wrote:
> As it currently stands, the sending side iterates from 0 to p2m_size,
> and sends every frame on the first pass. This means we get PAGE_DATA
> records linearly, in batches of 1024, or two aligned 2M superpages.
Is there a way to preserve 1G pages? This
On 20/04/17 16:35, Olaf Hering wrote:
> Andrew,
>
> with eab806a097b ("tools/libxc: x86 PV restore code") the only call of
> xc_domain_populate_physmap_exact was added to the new restore code.
> This call always sets order=0. The old migration code did consider
> superpages, the new one does not.
Andrew,
with eab806a097b ("tools/libxc: x86 PV restore code") the only call of
xc_domain_populate_physmap_exact was added to the new restore code.
This call always sets order=0. The old migration code did consider
superpages, the new one does not.
What is the reason for not using superpages when