All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "T.J. Alumbaugh" <talumbau@google.com>
Cc: qemu-devel@nongnu.org, "David Hildenbrand" <david@redhat.com>,
	"Yuanchu Xie" <yuanchu@google.com>, "Yu Zhao" <yuzhao@google.com>,
	"Dr. David Alan Gilbert" <dave@treblig.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Eric Blake" <eblake@redhat.com>
Subject: Re: [RFC PATCH v2 0/5] virtio-balloon: Working Set Reporting
Date: Mon, 7 Apr 2025 05:39:01 -0400	[thread overview]
Message-ID: <20250407053811-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230525222016.35333-1-talumbau@google.com>

On Thu, May 25, 2023 at 10:20:11PM +0000, T.J. Alumbaugh wrote:
> This is the device implementation for the proposed expanded balloon feature
> described here:
> 
> https://lore.kernel.org/linux-mm/20230509185419.1088297-1-yuanchu@google.com/
> 
> This series has a fixed number of "bins" for the working set report, but this is
> not a constraint of the system. The bin number is fixed at device realization
> time (in other implementations it is specified as a command line argument). Once
> that number is fixed, this determines the correct number of bin intervals to
> pass to the QMP/HMP function 'working_set_config'. Any feedback on how to
> properly construct that function for this use case (passing a variable length
> list?) would be appreciated.

It's been a while. Is there interest is reviving this? I also note that
reserving a feature bit is very much recommended to avoid a complete
mess.


> New in V2:
> =========
> 
> - Patch series is now: header file changes, device changes, QMP changes, HMP
> chagnes, and migration changes.
> 
> - Exmaple usages of QMP and HMP interface are in their respective commit
> messages.
> 
> - "ws" -> "working_set" throughout
> 
> Motivation
> ==========
> As mentioned in the above message, the use case is a host with overcommitted
> memory and 1 or more VMs. The goal is to get both timely and accurate
> information on overall memory utilization in order to drive appropriate
> reclaim activities, since in some client device use cases a VM might need a
> significant fraction of the overall memory for a period of time, but then
> enter a quiet period that results in a large number of cold pages in the
> guest.
> 
> The balloon device now has a number of features to assist in sharing memory
> resources amongst the guests and host (e.g free page hinting, stats, free page
> reporting). As mentioned in slide 12 in [1], the balloon doesn't have a good
> mechanism to drive the reclaim of guest cache. Our use case includes both
> typical page cache as well as "application caches" with memory that should be
> discarded in times of system-wide memory pressure. In some cases, virtio-pmem
> can be a method for host control of guest cache but there are undesirable
> security implications.
> 
> Working Set Reporting
> =====================
> The patch series here includes:
> 
>  - Actual device implementation for VIRTIO_F_WS_REPORTING to standardize the
>    configuration and communication of Working Set reports from the guest. This
>    includes a notification virtqueue for receiving config information and
>    requests for a report (a feature which could be expanded for additional use
>    cases) and a virtqueue for the actual report from the driver.
> 
>  - QMP changes so that a controller program can use the existing QEMU socket
>    mechanism to configure and request WS reports and then read the reports as
>    a JSON property on the balloon.
> 
> Working Set reporting in the balloon provides:
> 
>  - an accurate picture of current memory utilization in the guest
>  - event driven reporting (with configurable rate limiting) to deliver reports
>    during times of memory pressure.
> 
> The reporting mechanism can be combined with a domain-specific balloon policy
> to drive the separate reclaim activities in a coordinated fashion.
> 
> TODOs:
> ======
>  -  A synchronization mechanism must be added to the functions that send WS
>     Config and WS Request, otherwise concurrent callers (through QMP) can mix
>     messages on the virtqueue sending the data to the driver.
> 
>  - The device currently has a hard-coded setting of 4 'bins' for a Working Set
>    report, whereas the specification calls for anywhere between 2 and 16.
> 
>  - A WS_EVENT notification through QMP should include the actual report,
>    whereas right now we query for that information right after a WS_EVENT is
>    received.
> 
> References:
> 
> [1] https://kvmforum2020.sched.com/event/eE4U/virtio-balloonpmemmem-managing-guest-memory-david-hildenbrand-michael-s-tsirkin-red-hat
> 
> T.J. Alumbaugh (5):
>   virtio-balloon: Add Working Set Reporting feature
>   virtio-balloon: device has Working Set Reporting
>   virtio-balloon: Add QMP functions for Working Set
>   virtio-balloon: Add HMP functions for Working Set
>   virtio-balloon: Migration of working set config
> 
>  hmp-commands.hx                               |  26 ++
>  hw/core/machine-hmp-cmds.c                    |  21 ++
>  hw/virtio/virtio-balloon-pci.c                |   2 +
>  hw/virtio/virtio-balloon.c                    | 239 +++++++++++++++++-
>  include/hw/virtio/virtio-balloon.h            |  13 +-
>  include/monitor/hmp.h                         |   2 +
>  .../standard-headers/linux/virtio_balloon.h   |  20 ++
>  include/sysemu/balloon.h                      |   9 +-
>  monitor/monitor.c                             |   1 +
>  qapi/machine.json                             |  66 +++++
>  qapi/misc.json                                |  26 ++
>  softmmu/balloon.c                             |  31 ++-
>  12 files changed, 449 insertions(+), 7 deletions(-)
> 
> -- 
> 2.41.0.rc0.172.g3f132b7071-goog



  parent reply	other threads:[~2025-04-07  9:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-25 22:20 [RFC PATCH v2 0/5] virtio-balloon: Working Set Reporting T.J. Alumbaugh
2023-05-25 22:20 ` [RFC PATCH v2 1/5] virtio-balloon: Add Working Set Reporting feature T.J. Alumbaugh
2023-05-31  8:12   ` David Hildenbrand
2023-05-31 10:28     ` Michael S. Tsirkin
2023-05-25 22:20 ` [RFC PATCH v2 2/5] virtio-balloon: device has Working Set Reporting T.J. Alumbaugh
2023-05-27  6:16   ` Markus Armbruster
2023-05-27  6:21   ` Markus Armbruster
2023-05-25 22:20 ` [RFC PATCH v2 3/5] virtio-balloon: Add QMP functions for Working Set T.J. Alumbaugh
2023-05-27  6:38   ` Markus Armbruster
2023-05-31  8:14   ` David Hildenbrand
2023-05-25 22:20 ` [RFC PATCH v2 4/5] virtio-balloon: Add HMP " T.J. Alumbaugh
2023-05-25 22:20 ` [RFC PATCH v2 5/5] virtio-balloon: Migration of working set config T.J. Alumbaugh
2023-05-31  8:18 ` [RFC PATCH v2 0/5] virtio-balloon: Working Set Reporting David Hildenbrand
2025-04-07  9:39 ` Michael S. Tsirkin [this message]
2025-04-09 16:52   ` Yuanchu Xie
2025-04-10  6:09     ` Michael S. Tsirkin

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=20250407053811-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dave@treblig.org \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=talumbau@google.com \
    --cc=wangyanan55@huawei.com \
    --cc=yuanchu@google.com \
    --cc=yuzhao@google.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.