On Fri, Aug 25, Olaf Hering wrote:
> I think with the new check of max_pages an overallocation can not happen
> anymore. If at some point the domU still has room for a superpage, it
> will be allocated. In case the batch does not fully fill the superpage,
> the holes will be freed. In the next
On Fri, Aug 25, Wei Liu wrote:
> Maybe a middle ground is to scan the batch to see if pfns can be fit
> into a whole super page? I don't think you can get a batch as big as 1G
> but there should be a lot of 2M batches?
I think with the new check of max_pages an overallocation can not happen
On Fri, Aug 25, 2017 at 02:51:01PM +0200, Olaf Hering wrote:
> On Fri, Aug 25, Wei Liu wrote:
>
> > I'm still unconvinced this works all the time because it still needs the
> > assumption that the stream contains contiguous pfns.
>
> This is how it is done today. If the pfns start to arrive in
On Fri, Aug 25, Wei Liu wrote:
> I'm still unconvinced this works all the time because it still needs the
> assumption that the stream contains contiguous pfns.
This is how it is done today. If the pfns start to arrive in another
order the format has to be changed to send a memory layout in
On Thu, Aug 24, 2017 at 12:14:43PM +0200, Olaf Hering wrote:
> During creating of a HVM domU meminit_hvm() tries to map superpages.
> After save/restore or migration this mapping is lost, everything is
> allocated in single pages. This causes a performance degradition after
> migration.
>
> Add
During creating of a HVM domU meminit_hvm() tries to map superpages.
After save/restore or migration this mapping is lost, everything is
allocated in single pages. This causes a performance degradition after
migration.
Add neccessary code to preallocate a superpage for the chunk of pfns
that is
