From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT 3086844] Instead of writing a zero page, madvise it away
Date: Mon, 22 Jun 2009 20:20:33 +0300 [thread overview]
Message-ID: <4A3FBD61.8030109@redhat.com> (raw)
In-Reply-To: <4A3FB95D.3060404@us.ibm.com>
On 06/22/2009 08:03 PM, Anthony Liguori wrote:
>>>
>>> 1) Start a guest with 1024, balloon down to 128MB. RSS size is now
>>> ~128MB
>>> 2) Live migrate to a different node
>>> 3) RSS on different node jumps to ~1GB
>>
>> 3.5) RSS on source node jumps to ~1GB, since reading the page
>> instantiates the pte
> I don't follow. In this case, the issue is:
>
> Surely we can do better here...
>
> For TCG, we always know when memory is dirty and we can check it
> atomically. So we know whether a page has changed since we knew it
> was last zero. We basically need a ZERO_DIRTY bit. All memory
> initially carries this bit and ballooning also sets the bit. During
> live migration, we can check the dirty bit first.
You mean, a NONZERO bit which is cleared by ballooning and set on any
write. This will work naturally with the qemu dirty bytemap.
>
> For KVM, we would have to enable dirty tracking always to keep
> ZERO_DIRTY up to date. Since write faults are going to happen anyway
> at start up, perhaps the cost of doing this wouldn't be so bad?
You need to do this on the source node. Unfortunately, there's no way
to initialize the values racelessly when you start live migration
without introducing a new ioctl. I'd like a more general solution
rather than something that targets this specific problem.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-06-22 17:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906221549.n5MFn3Qd015389@d03av02.boulder.ibm.com>
2009-06-22 16:12 ` [Qemu-devel] Re: [Qemu-commits] [COMMIT 3086844] Instead of writing a zero page, madvise it away Avi Kivity
2009-06-22 16:25 ` Anthony Liguori
2009-06-22 16:38 ` Avi Kivity
2009-06-22 16:58 ` Anthony Liguori
2009-06-22 17:12 ` Avi Kivity
2009-06-22 17:03 ` Anthony Liguori
2009-06-22 17:20 ` Avi Kivity [this message]
2009-06-22 17:37 ` Anthony Liguori
2009-06-22 18:01 ` Avi Kivity
2009-06-22 17:44 ` Anthony Liguori
2009-06-22 18:04 ` Avi Kivity
2009-06-22 19:38 ` Paul Brook
2009-06-22 19:49 ` Anthony Liguori
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=4A3FBD61.8030109@redhat.com \
--to=avi@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).