[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65de00cf-5969-ea2e-545b-2228a4c859b0@redhat.com>
Date: Thu, 28 Nov 2019 16:25:54 +0100
From: David Hildenbrand <david@...hat.com>
To: Alexander Duyck <alexander.duyck@...il.com>, kvm@...r.kernel.org,
mst@...hat.com, linux-kernel@...r.kernel.org, willy@...radead.org,
mhocko@...nel.org, linux-mm@...ck.org, akpm@...ux-foundation.org,
mgorman@...hsingularity.net, vbabka@...e.cz
Cc: yang.zhang.wz@...il.com, nitesh@...hat.com, konrad.wilk@...cle.com,
pagupta@...hat.com, riel@...riel.com, lcapitulino@...hat.com,
dave.hansen@...el.com, wei.w.wang@...el.com, aarcange@...hat.com,
pbonzini@...hat.com, dan.j.williams@...el.com,
alexander.h.duyck@...ux.intel.com, osalvador@...e.de
Subject: Re: [PATCH v14 6/6] virtio-balloon: Add support for providing unused
page reports to host
On 19.11.19 22:46, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
>
> Add support for the page reporting feature provided by virtio-balloon.
> Reporting differs from the regular balloon functionality in that is is
> much less durable than a standard memory balloon. Instead of creating a
> list of pages that cannot be accessed the pages are only inaccessible
> while they are being indicated to the virtio interface. Once the
> interface has acknowledged them they are placed back into their respective
> free lists and are once again accessible by the guest system.
Maybe add something like "In contrast to ordinary balloon
inflation/deflation, the guest can reuse all reported pages immediately
after reporting has finished, without having to notify the hypervisor
about it (e.g., VIRTIO_BALLOON_F_MUST_TELL_HOST does not apply)."
[...]
> /*
> * Balloon device works in 4K page units. So each page is pointed to by
> @@ -37,6 +38,9 @@
> #define VIRTIO_BALLOON_FREE_PAGE_SIZE \
> (1 << (VIRTIO_BALLOON_FREE_PAGE_ORDER + PAGE_SHIFT))
>
> +/* limit on the number of pages that can be on the reporting vq */
> +#define VIRTIO_BALLOON_VRING_HINTS_MAX 16
Maybe rename that from HINTS to REPORTS
> +
> #ifdef CONFIG_BALLOON_COMPACTION
> static struct vfsmount *balloon_mnt;
> #endif
> @@ -46,6 +50,7 @@ enum virtio_balloon_vq {
> VIRTIO_BALLOON_VQ_DEFLATE,
> VIRTIO_BALLOON_VQ_STATS,
> VIRTIO_BALLOON_VQ_FREE_PAGE,
> + VIRTIO_BALLOON_VQ_REPORTING,
> VIRTIO_BALLOON_VQ_MAX
> };
>
> @@ -113,6 +118,10 @@ struct virtio_balloon {
>
> /* To register a shrinker to shrink memory upon memory pressure */
> struct shrinker shrinker;
> +
> + /* Unused page reporting device */
Sounds like the device is unused :D
"Device info for reporting unused pages" ?
I am in general wondering, should we rename "unused" to "free". I.e.,
"free page reporting" instead of "unused page reporting"? Or what was
the motivation behind using "unused" ?
> + struct virtqueue *reporting_vq;
> + struct page_reporting_dev_info pr_dev_info;
> };
>
> static struct virtio_device_id id_table[] = {
> @@ -152,6 +161,32 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
>
> }
>
> +void virtballoon_unused_page_report(struct page_reporting_dev_info *pr_dev_info,
> + unsigned int nents)
> +{
> + struct virtio_balloon *vb =
> + container_of(pr_dev_info, struct virtio_balloon, pr_dev_info);
> + struct virtqueue *vq = vb->reporting_vq;
> + unsigned int unused, err;
> +
> + /* We should always be able to add these buffers to an empty queue. */
This comment somewhat contradicts the error handling (and comment)
below. Maybe just drop it?
> + err = virtqueue_add_inbuf(vq, pr_dev_info->sg, nents, vb,
> + GFP_NOWAIT | __GFP_NOWARN);
> +
> + /*
> + * In the extremely unlikely case that something has changed and we
> + * are able to trigger an error we will simply display a warning
> + * and exit without actually processing the pages.
> + */
> + if (WARN_ON(err))
> + return;
Maybe WARN_ON_ONCE? (to not flood the log on recurring errors)
> +
> + virtqueue_kick(vq);
> +
> + /* When host has read buffer, this completes via balloon_ack */
> + wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
Is it safe to rely on the same ack-ing mechanism as the inflate/deflate
queue? What if both mechanisms are used concurrently and race/both wait
for the hypervisor?
Maybe we need a separate vb->acked + callback function.
> +}
> +
> static void set_page_pfns(struct virtio_balloon *vb,
> __virtio32 pfns[], struct page *page)
> {
> @@ -476,6 +511,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_REPORTING] = NULL;
>
> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> @@ -487,11 +523,19 @@ static int init_vqs(struct virtio_balloon *vb)
> callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> }
>
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> + names[VIRTIO_BALLOON_VQ_REPORTING] = "reporting_vq";
> + callbacks[VIRTIO_BALLOON_VQ_REPORTING] = balloon_ack;
> + }
> +
> 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_REPORTING))
> + vb->reporting_vq = vqs[VIRTIO_BALLOON_VQ_REPORTING];
> +
I'd register these in the same order they are defined (IOW, move this
further down)
> 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)) {
> @@ -932,12 +976,30 @@ static int virtballoon_probe(struct virtio_device *vdev)
> if (err)
> goto out_del_balloon_wq;
> }
> +
> + vb->pr_dev_info.report = virtballoon_unused_page_report;
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> + unsigned int capacity;
> +
> + capacity = min_t(unsigned int,
> + virtqueue_get_vring_size(vb->reporting_vq),
> + VIRTIO_BALLOON_VRING_HINTS_MAX);
> + vb->pr_dev_info.capacity = capacity;
> +
> + err = page_reporting_register(&vb->pr_dev_info);
> + if (err)
> + goto out_unregister_shrinker;
> + }
It can happen here that we start reporting before marking the device
ready. Can that be problematic?
Maybe we have to ignore any reports in virtballoon_unused_page_report()
until ready...
> +
> virtio_device_ready(vdev);
>
> if (towards_target(vb))
> virtballoon_changed(vdev);
> return 0;
>
> +out_unregister_shrinker:
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> + virtio_balloon_unregister_shrinker(vb);
A sync is done implicitly, right? So after this call, we won't get any
new callbacks/are stuck in a callback.
> out_del_balloon_wq:
> if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> destroy_workqueue(vb->balloon_wq);
> @@ -966,6 +1028,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
> {
> struct virtio_balloon *vb = vdev->priv;
>
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
> + page_reporting_unregister(&vb->pr_dev_info);
Dito, same question regarding syncs.
> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> virtio_balloon_unregister_shrinker(vb);
> spin_lock_irq(&vb->stop_update_lock);
> @@ -1038,6 +1102,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
> VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> VIRTIO_BALLOON_F_FREE_PAGE_HINT,
> VIRTIO_BALLOON_F_PAGE_POISON,
> + VIRTIO_BALLOON_F_REPORTING,
> };
>
> static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index a1966cd7b677..19974392d324 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -36,6 +36,7 @@
> #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */
> #define VIRTIO_BALLOON_F_FREE_PAGE_HINT 3 /* VQ to report free pages */
> #define VIRTIO_BALLOON_F_PAGE_POISON 4 /* Guest is using page poisoning */
> +#define VIRTIO_BALLOON_F_REPORTING 5 /* Page reporting virtqueue */
>
> /* Size of a PFN in the balloon interface. */
> #define VIRTIO_BALLOON_PFN_SHIFT 12
>
>
Small and powerful patch :)
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists