From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Hui Zhu <teawater@gmail.com>,
jasowang@redhat.com, akpm@linux-foundation.org,
pagupta@redhat.com, mojha@codeaurora.org, namit@vmware.com,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
Hui Zhu <teawaterz@linux.alibaba.com>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>
Subject: Re: [RFC for Linux] virtio_balloon: Add VIRTIO_BALLOON_F_THP_ORDER to handle THP spilt issue
Date: Thu, 26 Mar 2020 03:10:10 -0400 [thread overview]
Message-ID: <20200326030833-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <45756694-560d-0276-d39e-cc2fd1c4e3a7@redhat.com>
On Thu, Mar 12, 2020 at 09:51:25AM +0100, David Hildenbrand wrote:
> On 12.03.20 09:47, Michael S. Tsirkin wrote:
> > On Thu, Mar 12, 2020 at 09:37:32AM +0100, David Hildenbrand wrote:
> >> 2. You are essentially stealing THPs in the guest. So the fastest
> >> mapping (THP in guest and host) is gone. The guest won't be able to make
> >> use of THP where it previously was able to. I can imagine this implies a
> >> performance degradation for some workloads. This needs a proper
> >> performance evaluation.
> >
> > I think the problem is more with the alloc_pages API.
> > That gives you exactly the given order, and if there's
> > a larger chunk available, it will split it up.
> >
> > But for balloon - I suspect lots of other users,
> > we do not want to stress the system but if a large
> > chunk is available anyway, then we could handle
> > that more optimally by getting it all in one go.
> >
> >
> > So if we want to address this, IMHO this calls for a new API.
> > Along the lines of
> >
> > struct page *alloc_page_range(gfp_t gfp, unsigned int min_order,
> > unsigned int max_order, unsigned int *order)
> >
> > the idea would then be to return at a number of pages in the given
> > range.
> >
> > What do you think? Want to try implementing that?
>
> You can just start with the highest order and decrement the order until
> your allocation succeeds using alloc_pages(), which would be enough for
> a first version. At least I don't see the immediate need for a new
> kernel API.
Well there's still a chance of splitting a big page if one
becomes available meanwhile. But OK.
> --
> Thanks,
>
> David / dhildenb
next prev parent reply other threads:[~2020-03-26 7:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 7:49 [RFC for Linux] virtio_balloon: Add VIRTIO_BALLOON_F_THP_ORDER to handle THP spilt issue Hui Zhu
2020-03-12 7:49 ` [RFC for QEMU] virtio-balloon: Add option thp-order to set VIRTIO_BALLOON_F_THP_ORDER Hui Zhu
2020-03-12 8:22 ` no-reply
2020-03-12 8:25 ` Michael S. Tsirkin
2020-03-17 10:13 ` teawater
2020-03-26 7:07 ` Michael S. Tsirkin
2020-03-12 8:18 ` [RFC for Linux] virtio_balloon: Add VIRTIO_BALLOON_F_THP_ORDER to handle THP spilt issue Michael S. Tsirkin
2020-03-12 8:37 ` David Hildenbrand
2020-03-12 8:47 ` Michael S. Tsirkin
2020-03-12 8:51 ` David Hildenbrand
2020-03-26 7:10 ` Michael S. Tsirkin [this message]
2020-03-26 7:20 ` Michael S. Tsirkin
2020-03-26 7:54 ` David Hildenbrand
2020-03-26 9:49 ` Michael S. Tsirkin
2020-03-31 10:35 ` David Hildenbrand
2020-03-31 13:24 ` Michael S. Tsirkin
2020-03-31 13:32 ` David Hildenbrand
2020-03-31 13:37 ` Michael S. Tsirkin
2020-03-31 14:03 ` David Hildenbrand
2020-03-31 14:07 ` Michael S. Tsirkin
2020-03-31 14:09 ` David Hildenbrand
2020-03-31 14:18 ` Michael S. Tsirkin
2020-03-31 14:29 ` David Hildenbrand
2020-03-31 14:34 ` David Hildenbrand
2020-03-31 15:28 ` Michael S. Tsirkin
2020-03-31 16:37 ` Nadav Amit
2020-04-01 9:48 ` David Hildenbrand
2020-04-02 4:02 ` teawater
2020-04-02 8:00 ` teawater
2020-04-02 12:37 ` Michael S. Tsirkin
2020-03-31 16:27 ` Nadav Amit
2020-04-01 11:21 ` David Hildenbrand
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=20200326030833-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=david@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mojha@codeaurora.org \
--cc=namit@vmware.com \
--cc=pagupta@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=teawater@gmail.com \
--cc=teawaterz@linux.alibaba.com \
--cc=virtualization@lists.linux-foundation.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).