On 26.05.23 00:20, 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.
>
> 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.
Could the config update be modeled using the config space instead?
Is the report asynchronous to the request, or how exactly do requests
and reports interact?
>
> - 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.
Can you briefly summarize what a bin is, how one would decide how many
bins one wants and what the whole purpose of a bin is?
Thanks!
--
Thanks,
David / dhildenb