All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: pagupta@redhat.com,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>,
	qemu-devel@nongnu.org, mojha@codeaurora.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, namit@vmware.com,
	Hui Zhu <teawaterz@linux.alibaba.com>,
	akpm@linux-foundation.org, jasowang@redhat.com,
	Hui Zhu <teawater@gmail.com>
Subject: Re: [RFC for Linux] virtio_balloon: Add VIRTIO_BALLOON_F_THP_ORDER to handle THP spilt issue
Date: Thu, 12 Mar 2020 04:47:11 -0400	[thread overview]
Message-ID: <20200312043859-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <3e1373f4-6ade-c651-ddde-6f04e78382f9@redhat.com>

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?

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
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, 12 Mar 2020 04:47:11 -0400	[thread overview]
Message-ID: <20200312043859-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <3e1373f4-6ade-c651-ddde-6f04e78382f9@redhat.com>

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?

-- 
MST


  reply	other threads:[~2020-03-12  8:47 UTC|newest]

Thread overview: 65+ 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 ` 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  7:49   ` Hui Zhu
2020-03-12  8:22   ` no-reply
2020-03-12  8:22     ` no-reply
2020-03-12  8:22     ` no-reply
2020-03-12  8:25   ` Michael S. Tsirkin
2020-03-12  8:25     ` Michael S. Tsirkin
2020-03-17 10:13     ` teawater
2020-03-17 10:13       ` teawater
2020-03-26  7:07       ` Michael S. Tsirkin
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:18   ` Michael S. Tsirkin
2020-03-12  8:37 ` David Hildenbrand
2020-03-12  8:37   ` David Hildenbrand
2020-03-12  8:47   ` Michael S. Tsirkin [this message]
2020-03-12  8:47     ` Michael S. Tsirkin
2020-03-12  8:51     ` David Hildenbrand
2020-03-12  8:51       ` David Hildenbrand
2020-03-26  7:10       ` Michael S. Tsirkin
2020-03-26  7:10         ` Michael S. Tsirkin
2020-03-26  7:20       ` Michael S. Tsirkin
2020-03-26  7:20         ` Michael S. Tsirkin
2020-03-26  7:54         ` David Hildenbrand
2020-03-26  7:54           ` David Hildenbrand
2020-03-26  9:49           ` Michael S. Tsirkin
2020-03-26  9:49             ` Michael S. Tsirkin
2020-03-31 10:35             ` David Hildenbrand
2020-03-31 10:35               ` David Hildenbrand
2020-03-31 13:24               ` Michael S. Tsirkin
2020-03-31 13:24                 ` Michael S. Tsirkin
2020-03-31 13:32                 ` David Hildenbrand
2020-03-31 13:32                   ` David Hildenbrand
2020-03-31 13:37                   ` Michael S. Tsirkin
2020-03-31 13:37                     ` Michael S. Tsirkin
2020-03-31 14:03                     ` David Hildenbrand
2020-03-31 14:03                       ` David Hildenbrand
2020-03-31 14:07                       ` Michael S. Tsirkin
2020-03-31 14:07                         ` Michael S. Tsirkin
2020-03-31 14:09                         ` David Hildenbrand
2020-03-31 14:09                           ` David Hildenbrand
2020-03-31 14:18                           ` Michael S. Tsirkin
2020-03-31 14:18                             ` Michael S. Tsirkin
2020-03-31 14:29                             ` David Hildenbrand
2020-03-31 14:29                               ` David Hildenbrand
2020-03-31 14:29                               ` David Hildenbrand
2020-03-31 14:34                               ` David Hildenbrand
2020-03-31 14:34                                 ` David Hildenbrand
2020-03-31 15:28                                 ` Michael S. Tsirkin
2020-03-31 15:28                                   ` Michael S. Tsirkin
2020-03-31 16:37                           ` Nadav Amit
2020-04-01  9:48                             ` David Hildenbrand
2020-04-01  9:48                               ` David Hildenbrand
2020-04-01  9:48                               ` David Hildenbrand
2020-04-02  4:02                               ` teawater
2020-04-02  4:02                                 ` teawater
2020-04-02  8:00                         ` teawater
2020-04-02  8:00                           ` teawater
2020-04-02 12:37                           ` Michael S. Tsirkin
2020-04-02 12:37                             ` Michael S. Tsirkin
2020-03-31 16:27                   ` Nadav Amit
2020-04-01 11:21                     ` David Hildenbrand
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=20200312043859-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 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.