From: David Hildenbrand <david@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
Nitesh Narayan Lal <nitesh@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Paolo Bonzini <pbonzini@redhat.com>,
lcapitulino@redhat.com, pagupta@redhat.com, wei.w.wang@intel.com,
Yang Zhang <yang.zhang.wz@gmail.com>,
Rik van Riel <riel@surriel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
dodgen@google.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
dhildenb@redhat.com, Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC][Patch v10 2/2] virtio-balloon: page_hinting: reporting to the host
Date: Tue, 4 Jun 2019 09:12:21 +0200 [thread overview]
Message-ID: <604c496d-4df0-dca9-76dd-048917a5d132@redhat.com> (raw)
In-Reply-To: <CAKgT0UdtHAvRd++enU3ouxebwV1T4KZbS_JkmyDbJ5jGkA1XaQ@mail.gmail.com>
On 04.06.19 00:38, Alexander Duyck wrote:
> On Mon, Jun 3, 2019 at 10:04 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> Enables the kernel to negotiate VIRTIO_BALLOON_F_HINTING feature with the
>> host. If it is available and page_hinting_flag is set to true, page_hinting
>> is enabled and its callbacks are configured along with the max_pages count
>> which indicates the maximum number of pages that can be isolated and hinted
>> at a time. Currently, only free pages of order >= (MAX_ORDER - 2) are
>> reported. To prevent any false OOM max_pages count is set to 16.
>>
>> By default page_hinting feature is enabled and gets loaded as soon
>> as the virtio-balloon driver is loaded. However, it could be disabled
>> by writing the page_hinting_flag which is a virtio-balloon parameter.
>>
>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
>> ---
>> drivers/virtio/virtio_balloon.c | 112 +++++++++++++++++++++++++++-
>> include/uapi/linux/virtio_balloon.h | 14 ++++
>> 2 files changed, 125 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
>> index f19061b585a4..40f09ea31643 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -31,6 +31,7 @@
>> #include <linux/mm.h>
>> #include <linux/mount.h>
>> #include <linux/magic.h>
>> +#include <linux/page_hinting.h>
>>
>> /*
>> * Balloon device works in 4K page units. So each page is pointed to by
>> @@ -48,6 +49,7 @@
>> /* The size of a free page block in bytes */
>> #define VIRTIO_BALLOON_FREE_PAGE_SIZE \
>> (1 << (VIRTIO_BALLOON_FREE_PAGE_ORDER + PAGE_SHIFT))
>> +#define VIRTIO_BALLOON_PAGE_HINTING_MAX_PAGES 16
>>
>> #ifdef CONFIG_BALLOON_COMPACTION
>> static struct vfsmount *balloon_mnt;
>> @@ -58,6 +60,7 @@ enum virtio_balloon_vq {
>> VIRTIO_BALLOON_VQ_DEFLATE,
>> VIRTIO_BALLOON_VQ_STATS,
>> VIRTIO_BALLOON_VQ_FREE_PAGE,
>> + VIRTIO_BALLOON_VQ_HINTING,
>> VIRTIO_BALLOON_VQ_MAX
>> };
>>
>> @@ -67,7 +70,8 @@ enum virtio_balloon_config_read {
>>
>> struct virtio_balloon {
>> struct virtio_device *vdev;
>> - struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
>> + struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq,
>> + *hinting_vq;
>>
>> /* Balloon's own wq for cpu-intensive work items */
>> struct workqueue_struct *balloon_wq;
>> @@ -125,6 +129,9 @@ struct virtio_balloon {
>>
>> /* To register a shrinker to shrink memory upon memory pressure */
>> struct shrinker shrinker;
>> +
>> + /* object pointing at the array of isolated pages ready for hinting */
>> + struct hinting_data *hinting_arr;
>
> Just make this an array of size VIRTIO_BALLOON_PAGE_HINTING_MAX_PAGES.
> It will save a bunch of complexity later.
+1
[...]
>
>> +struct virtio_balloon *hvb;
>> +bool page_hinting_flag = true;
>> +module_param(page_hinting_flag, bool, 0444);
>> +MODULE_PARM_DESC(page_hinting_flag, "Enable page hinting");
>> +
>> +static bool virtqueue_kick_sync(struct virtqueue *vq)
>> +{
>> + u32 len;
>> +
>> + if (likely(virtqueue_kick(vq))) {
>> + while (!virtqueue_get_buf(vq, &len) &&
>> + !virtqueue_is_broken(vq))
>> + cpu_relax();
>> + return true;
>
> Is this a synchronous setup? It seems kind of wasteful to have a
> thread busy waiting here like this. It might make more sense to just
> make this work like the other balloon queues and have a wait event
> with a wake up in the interrupt handler for the queue.
+1
[...]
>
>> + gpaddr = virt_to_phys(hvb->hinting_arr);
>> + hint_req->phys_addr = cpu_to_virtio64(hvb->vdev, gpaddr);
>> + hint_req->size = cpu_to_virtio32(hvb->vdev, entries);
>> + sg_init_one(&sg, hint_req, sizeof(*hint_req));
>> + err = virtqueue_add_outbuf(vq, &sg, 1, hint_req, GFP_KERNEL);
>> + if (!err)
>> + virtqueue_kick_sync(hvb->hinting_vq);
>> +
>> + kfree(hint_req);
>> +}
>> +
>> +int page_hinting_prepare(void)
>> +{
>> + hvb->hinting_arr = kmalloc_array(VIRTIO_BALLOON_PAGE_HINTING_MAX_PAGES,
>> + sizeof(*hvb->hinting_arr), GFP_KERNEL);
>> + if (!hvb->hinting_arr)
>> + return -ENOMEM;
>> + return 0;
>> +}
>> +
>
> Why make the hinting_arr a dynamic allocation? You should probably
> just make it a static array within the virtio_balloon structure. Then
> you don't have the risk of an allocation failing and messing up the
> hints.
+1
>
>> +void hint_pages(struct list_head *pages)
>> +{
>> + struct page *page, *next;
>> + unsigned long pfn;
>> + int idx = 0, order;
>> +
>> + list_for_each_entry_safe(page, next, pages, lru) {
>> + pfn = page_to_pfn(page);
>> + order = page_private(page);
>> + hvb->hinting_arr[idx].phys_addr = pfn << PAGE_SHIFT;
>> + hvb->hinting_arr[idx].size = (1 << order) * PAGE_SIZE;
>> + idx++;
>> + }
>> + page_hinting_report(idx);
>> +}
>> +
>
> Getting back to my suggestion from earlier today. It might make sense
> to not bother with the PAGE_SHIFT or PAGE_SIZE multiplication if you
> just record everything in VIRTIO_BALLOON_PAGES intead of using the
> actual address and size.
I think I prefer "addr + size".
>
> Same comment here. Make this array a part of virtio_balloon and you
> don't have to free it.
>
>> +static const struct page_hinting_cb hcb = {
>> + .prepare = page_hinting_prepare,
>> + .hint_pages = hint_pages,
>> + .cleanup = page_hinting_cleanup,
>> + .max_pages = VIRTIO_BALLOON_PAGE_HINTING_MAX_PAGES,
>> +};
>
> With the above changes prepare and cleanup can be dropped.
+1
>
>> +#endif
>> +
>> static u32 page_to_balloon_pfn(struct page *page)
>> {
>> unsigned long pfn = page_to_pfn(page);
>> @@ -488,6 +574,7 @@ static int init_vqs(struct virtio_balloon *vb)
>> names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>> names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>> names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> + names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>>
>> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> names[VIRTIO_BALLOON_VQ_STATS] = "stats";
>> @@ -499,11 +586,18 @@ static int init_vqs(struct virtio_balloon *vb)
>> callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> }
>>
>> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
>> + names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
>> + callbacks[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>> + }
>> err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>> vqs, callbacks, names, NULL, NULL);
>> if (err)
>> return err;
>>
>> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> + vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
>> +
>> vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>> vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> @@ -942,6 +1036,14 @@ static int virtballoon_probe(struct virtio_device *vdev)
>> if (err)
>> goto out_del_balloon_wq;
>> }
>> +
>> +#ifdef CONFIG_PAGE_HINTING
>> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING) &&
>> + page_hinting_flag) {
>> + hvb = vb;
>> + page_hinting_enable(&hcb);
>> + }
>> +#endif
>> virtio_device_ready(vdev);
>>
>> if (towards_target(vb))
>> @@ -989,6 +1091,12 @@ static void virtballoon_remove(struct virtio_device *vdev)
>> destroy_workqueue(vb->balloon_wq);
>> }
>>
>> +#ifdef CONFIG_PAGE_HINTING
>> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
Nitesh, you should only disable if you actually enabled it
(page_hinting_flag).
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-06-04 7:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 17:03 [RFC][Patch v10 0/2] mm: Support for page hinting Nitesh Narayan Lal
2019-06-03 17:03 ` [RFC][Patch v10 1/2] mm: page_hinting: core infrastructure Nitesh Narayan Lal
2019-06-03 19:04 ` Alexander Duyck
2019-06-04 12:55 ` Nitesh Narayan Lal
2019-06-04 15:14 ` Alexander Duyck
2019-06-04 16:07 ` Nitesh Narayan Lal
2019-06-04 16:25 ` Alexander Duyck
2019-06-04 16:42 ` Nitesh Narayan Lal
2019-06-04 17:12 ` Alexander Duyck
2019-06-03 19:57 ` David Hildenbrand
2019-06-04 13:16 ` Nitesh Narayan Lal
2019-06-14 7:24 ` David Hildenbrand
2019-06-03 17:03 ` [RFC][Patch v10 2/2] virtio-balloon: page_hinting: reporting to the host Nitesh Narayan Lal
2019-06-03 22:38 ` Alexander Duyck
2019-06-04 7:12 ` David Hildenbrand [this message]
2019-06-04 11:50 ` Nitesh Narayan Lal
2019-06-04 11:31 ` Nitesh Narayan Lal
2019-06-04 16:33 ` Alexander Duyck
2019-06-04 16:44 ` Nitesh Narayan Lal
2019-06-03 17:04 ` [QEMU PATCH] KVM: Support for page hinting Nitesh Narayan Lal
2019-06-03 18:34 ` Alexander Duyck
2019-06-03 18:37 ` Nitesh Narayan Lal
2019-06-03 18:45 ` Nitesh Narayan Lal
2019-06-04 16:41 ` Alexander Duyck
2019-06-04 16:48 ` Nitesh Narayan Lal
2019-06-03 18:04 ` [RFC][Patch v10 0/2] mm: " Michael S. Tsirkin
2019-06-03 18:38 ` Nitesh Narayan Lal
2019-06-11 12:19 ` Nitesh Narayan Lal
2019-06-11 15:00 ` Alexander Duyck
2019-06-25 14:48 ` Nitesh Narayan Lal
2019-06-25 17:10 ` Alexander Duyck
2019-06-25 17:31 ` Nitesh Narayan Lal
2019-06-28 18:25 ` Alexander Duyck
2019-06-28 19:13 ` Nitesh Narayan Lal
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=604c496d-4df0-dca9-76dd-048917a5d132@redhat.com \
--to=david@redhat.com \
--cc=aarcange@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=dhildenb@redhat.com \
--cc=dodgen@google.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=nitesh@redhat.com \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@surriel.com \
--cc=wei.w.wang@intel.com \
--cc=yang.zhang.wz@gmail.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 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).