qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC migration of zero pages


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] RFC migration of zero pages
Date: Thu, 31 Jan 2013 23:18:44 +0200

On Thu, Jan 31, 2013 at 05:20:02PM +0200, Avi Kivity wrote:
> On Thu, Jan 31, 2013 at 4:42 PM, Gleb Natapov <address@hidden> wrote:
> > On Thu, Jan 31, 2013 at 04:36:25PM +0200, Avi Kivity wrote:
> >> On Thu, Jan 31, 2013 at 4:30 PM, Gleb Natapov <address@hidden> wrote:
> >> >> >
> >> >> > Avi/Michael do you remember why mincore can't be used to check if a 
> >> >> > guest
> >> >> page is unmapped?
> >> >>
> >> >> A page may be not in core, but also nonzero (for example swap).
> >> > Yes, mincore() should not be used as zero page check, but it can be used
> >> > as an indicator that page can be dealt with in dead stage of migration
> >> > since it is likely zero and will not take much time to send.
> >>
> >> Or it's swapped, in which case we know nothing about it.
> >>
> >> > It is
> > Of course, that is why I said "likely' :)
> >
> >> > possible to call madvise(MADV_WILLNEED) on them meanwhile to pre-load
> >> > swap without faulting on each page individually.
> >>
> >> During migration you're faulting like mad anyway.
> > That's guest faulting on dirty bit logging, as far as I understand Orit
> > says that in addition to that she sees a lot of faults generated by
> > migration reading unmapped guest memory. She wants to eliminate at least
> > those.
> 
> For that, we once talked about extending mincore() to return info
> whether a page is known zero (anonymous memory without a backing page,
> or backing page == zero page).

Shoudn't be hard to expose in /proc, no?

> But I doubt it's worth it, yes we're
> faulting a lot, but it's still a lot cheaper than actually sending a
> page, so we're still ahead of a non-idle guest.

It's not just fault, reading in the page is bad for the cache.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]