[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: Straw linux/lguest implementation of new "memballoon"
Amit Shah <amit.shah@redhat.com> writes: > On (Wed) 28 May 2014 [17:09:16], Rusty Russell wrote: >> You're right. I've deleted that sentence; we need to have a discussion >> on whether stats are actually valuable as they are today. > > What would a guest admin allow a host admin to know? > 1. How much memory the guest was started with > 2. Did the guest ask for extra pages (negative balloon) > 3. What is the size of the current balloon Well, the host knows all these things. > In addition, a host admin would like to know (well, it'd like to know > a lot more, but being realistic): > 4. Did the guest refuse to give it memory when asked? How many times? > 5. Did the guest voluntarily give up memory when not asked for (min > going beyond the min balloon) It knows this, too. The legacy ballon stats interface published stats about the guest VM, such as: #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */ #define VIRTIO_BALLOON_S_SWAP_OUT 1 /* Amount of memory swapped out */ #define VIRTIO_BALLOON_S_MAJFLT 2 /* Number of major faults */ #define VIRTIO_BALLOON_S_MINFLT 3 /* Number of minor faults */ #define VIRTIO_BALLOON_S_MEMFREE 4 /* Total amount of free memory */ #define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */ With the guest controlling the balloon, it's not clear these are needed. >> > Also, if a device gives control of 2 out of 5 requested pages, which >> > pages were the ones the device gave back? >> >> The first two. > > Should this be explicit? I think so. Yes: diff --git a/content.tex b/content.tex index e7c64b2..745a29e 100644 --- a/content.tex +++ b/content.tex @@ -5179,10 +5179,24 @@ it didn't put in). \item The driver constructs a buffer of le64 values. The first is device-readable VIRTIO_MEMBALLOON_GCMD_GET_PAGES, followed by one or more device-readable 64-bit page addresses of pages it wants, - followed by a final device-writabe 64-bit value. + followed by a final device-writable 64-bit value. +\begin{note} + For example, if the driver were to ask for 3 pages back, at + addresses 0x1000, 0x2000 and 0x3000, the request would contain 5 64-bit + values (4 device-readable followed by 1 device-writable): + \begin{lstlisting} + 0 0x1000 0x2000 0x3000 0 + \end{lstlisting} +\end{note} \item The driver places the buffer into the todevq and notifies the device. -\item When the device has finished with the buffer, the final 64-bit value - indicates the number of pages which were successfully obtained. +\item When the device has finished with the buffer, the final 64-bit + value indicates the number of pages (in requested order) which were + successfully obtained. +\begin{note} + To continue the previous example, if the device could only return 2 + pages, it would return the pages 0x1000 and 0x2000 and write ``2'' + in the final field. +\end{note} \end{enumerate} \subsubsection{Exchanging Pages With The Balloon}\label{sec:Device Types / Memory Balloon Device / Device Operation / Exchanging Pages With The Balloon} Cheers, Rusty.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]