From: Anthony Liguori <anthony@codemonkey.ws>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: qemu-devel@nongnu.org, Rusty Russell <rusty@ozlabs.au.ibm.com>,
kvm-devel <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [5874] Add virtio-balloon support
Date: Thu, 04 Dec 2008 16:34:42 -0600 [thread overview]
Message-ID: <49385B02.9010206@codemonkey.ws> (raw)
In-Reply-To: <1228426490.19459.44.camel@localhost.localdomain>
Hollis Blanchard wrote:
> On Thu, 2008-12-04 at 20:33 +0000, Anthony Liguori wrote:
>
>> +static void balloon_page(void *addr, int deflate)
>> +{
>> +#if defined(__linux__)
>> + if (!kvm_enabled() || kvm_has_sync_mmu())
>> + madvise(addr, TARGET_PAGE_SIZE,
>> + deflate ? MADV_WILLNEED : MADV_DONTNEED);
>> +#endif
>> +}
>>
>
> Hmm, I just noticed this... we need to use VIRTIO_BALLOON_PFN_SHIFT like
> Rusty did on the kernel side.
>
> However, in general I'm not sure how this is supposed to work. Isn't it
> true that madvise() is a no-op if 0 < length < getpagesize()? If so, how
> should the guest know the chunk size needed on the host?
>
We need to pass multiple of TARGET_PAGE_SIZE to madvise() but we can
certainly adjust that depending on VIRTIO_BALLOON_PFN_SHIFT. But
basically, if the two aren't equal, we shouldn't even try madvise().
> What happens when a guest tries to balloon 4K pages when it's backed on
> the host by hugetlbfs? We can't even use getpagesize() there.
>
Nothing. For ballooning to work in this circumstance, the guest would
have to balloon 2MB pages which isn't something that's reasonable for it
to do.
> Maybe the virtio balloon interface needs to advertise a unit size from
> the host, and use that size instead of alloc_page() in the guest?
>
That's a possibility. May make sense to give it the ability to balloon
memory up to unit size because I don't think it'll be able to meet the
reservation for large pages only.
Regards,
Anthony Liguori
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: Rusty Russell <rusty@ozlabs.au.ibm.com>,
qemu-devel@nongnu.org, kvm-devel <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [5874] Add virtio-balloon support
Date: Thu, 04 Dec 2008 16:34:42 -0600 [thread overview]
Message-ID: <49385B02.9010206@codemonkey.ws> (raw)
In-Reply-To: <1228426490.19459.44.camel@localhost.localdomain>
Hollis Blanchard wrote:
> On Thu, 2008-12-04 at 20:33 +0000, Anthony Liguori wrote:
>
>> +static void balloon_page(void *addr, int deflate)
>> +{
>> +#if defined(__linux__)
>> + if (!kvm_enabled() || kvm_has_sync_mmu())
>> + madvise(addr, TARGET_PAGE_SIZE,
>> + deflate ? MADV_WILLNEED : MADV_DONTNEED);
>> +#endif
>> +}
>>
>
> Hmm, I just noticed this... we need to use VIRTIO_BALLOON_PFN_SHIFT like
> Rusty did on the kernel side.
>
> However, in general I'm not sure how this is supposed to work. Isn't it
> true that madvise() is a no-op if 0 < length < getpagesize()? If so, how
> should the guest know the chunk size needed on the host?
>
We need to pass multiple of TARGET_PAGE_SIZE to madvise() but we can
certainly adjust that depending on VIRTIO_BALLOON_PFN_SHIFT. But
basically, if the two aren't equal, we shouldn't even try madvise().
> What happens when a guest tries to balloon 4K pages when it's backed on
> the host by hugetlbfs? We can't even use getpagesize() there.
>
Nothing. For ballooning to work in this circumstance, the guest would
have to balloon 2MB pages which isn't something that's reasonable for it
to do.
> Maybe the virtio balloon interface needs to advertise a unit size from
> the host, and use that size instead of alloc_page() in the guest?
>
That's a possibility. May make sense to give it the ability to balloon
memory up to unit size because I don't think it'll be able to meet the
reservation for large pages only.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2008-12-04 22:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-04 20:33 [Qemu-devel] [5874] Add virtio-balloon support Anthony Liguori
2008-12-04 21:34 ` Hollis Blanchard
2008-12-04 22:34 ` Anthony Liguori [this message]
2008-12-04 22:34 ` Anthony Liguori
2008-12-05 14:14 ` Paul Brook
2008-12-05 14:14 ` [Qemu-devel] " Paul Brook
2008-12-05 14:21 ` Anthony Liguori
2008-12-05 14:21 ` 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=49385B02.9010206@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=hollisb@us.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@ozlabs.au.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.