From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCPRh-00089r-MB for qemu-devel@nongnu.org; Mon, 13 Jun 2016 06:50:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCPRe-0001Hm-1U for qemu-devel@nongnu.org; Mon, 13 Jun 2016 06:50:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCPRd-0001Hg-QF for qemu-devel@nongnu.org; Mon, 13 Jun 2016 06:50:13 -0400 Date: Mon, 13 Jun 2016 11:50:08 +0100 From: "Daniel P. Berrange" Message-ID: <20160613105008.GJ18794@redhat.com> Reply-To: "Daniel P. Berrange" References: <1465813009-21390-1-git-send-email-liang.z.li@intel.com> <1465813009-21390-4-git-send-email-liang.z.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1465813009-21390-4-git-send-email-liang.z.li@intel.com> Subject: Re: [Qemu-devel] [QEMU 3/7] Add the hmp and qmp interface for dropping cache List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liang Li Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, quintela@redhat.com, mst@redhat.com, dgilbert@redhat.com, lcapitulino@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com On Mon, Jun 13, 2016 at 06:16:45PM +0800, Liang Li wrote: > Add the hmp and qmp interface to drop vm's page cache, users > can control the type of cache they want vm to drop. > > Signed-off-by: Liang Li > --- > balloon.c | 19 +++++++++++++++++++ > hmp-commands.hx | 15 +++++++++++++++ > hmp.c | 22 ++++++++++++++++++++++ > hmp.h | 3 +++ > monitor.c | 18 ++++++++++++++++++ > qapi-schema.json | 35 +++++++++++++++++++++++++++++++++++ > qmp-commands.hx | 23 +++++++++++++++++++++++ > 7 files changed, 135 insertions(+) > diff --git a/qapi-schema.json b/qapi-schema.json > index 8483bdf..117f70a 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -1655,6 +1655,41 @@ > { 'command': 'balloon', 'data': {'value': 'int'} } > > ## > +# @DropCacheType > +# > +# Cache types enumeration > +# > +# @clean: Drop the clean page cache. > +# > +# @slab: Drop the slab cache. > +# > +# @all: Drop both the clean and the slab cache. > +# > +# Since: 2.7 > +## > +{ 'enum': 'DropCacheType', 'data': ['clean', 'slab', 'all'] } Presumably these constants are corresponding to the 3 options for vm.drop_caches sysctl knob [quote] To free pagecache, use: echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes, use: echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes, use: echo 3 > /proc/sys/vm/drop_caches Because writing to this file is a nondestructive operation and dirty objects are not freeable, the user should run sync(1) first. [/quote] IOW, by 'slab' you mean dentries and inodes ? > + > +## > +# @balloon_drop_cache: > +# > +# Request the vm to drop its cache. > +# > +# @value: the type of cache want vm to drop > +# > +# Returns: Nothing on success > +# If the balloon driver is enabled but not functional because the KVM > +# kernel module cannot support it, KvmMissingCap > +# If no balloon device is present, DeviceNotActive > +# > +# Notes: This command just issues a request to the guest. When it returns, > +# the drop cache operation may not have completed. A guest can drop its > +# cache independent of this command. > +# > +# Since: 2.7.0 > +## > +{ 'command': 'balloon_drop_cache', 'data': {'value': 'DropCacheType'} } Also, as noted in the man page quote above, it is recommended to call sync() to minimise dirty pages. Should we have a way to request a sync as part of this monitor command. More generally, it feels like this is taking as down a path towards actively managing the guest kernel VM from the host. Is this really a path we want to be going down, given that its going to take us into increasing non-portable concepts which are potentially different for each guest OS kernel. Is this drop caches feature at all applicable to Windows, OS-X, *BSD guest OS impls of the balloon driver ? If it is applicable, are the 3 fixed constants you've defined at all useful to those other OS ? I'm warying of us taking a design path which is so Linux specific it isn't useful elsewhere. IOW, just because we can do this, doesn't mean we should do this... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|