| Message ID | 1465813009-21390-4-git-send-email-liang.z.li@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <liang.z.li@intel.com> > --- > 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
On Mon, Jun 13, 2016 at 11:50:08AM +0100, Daniel P. Berrange wrote: > 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 <liang.z.li@intel.com> > > --- > > 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... Also, I'm wondering about the overall performance benefit of dropping guest cache(s). Increasing the amount of free memory pages may have a benefit in terms of reducing data that needs to be migrated, but it comes with a penalty that if the guest OS needs that data, it will have to repopulate the caches. If the guest is merely reading those cached pages, it isn't going to cause any problem with chances of convergance of migration, as clean pages will be copied only once during migration. IOW, dropping clean pages will reduce the total memory that needs to be copied, but won't have notable affect on convergance of live migration. Cache pages that are dirty will potentially affect live migration convergance, if the guest OS re-dirties the pages before they're flushed to storage. Dropping caches won't help in this respect though, since you can't drop dirty pages. At the same time it will have a potentially significant negative penalty on guest OS performance by forcing the guest to re-populate the cache from slow underlying storage. I don't think there's enough info exposed by KVM about the guest OS to be able to figure out what kind of situation we're in wrt the guest OS cache usage. Based on this I think it is hard to see how a host mgmt app can make a well informed decision about whether telling the guest OS to drop caches is a positive thing overall. In fact I think most likely is that a mgmt app would take a pessimistic view and not use this functionality, because there's no clearly positive impact on migration convergance and high liklihood of negatively impacting guest performance. Regards, Daniel
On 13/06/2016 12:50, Daniel P. Berrange wrote: > 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... I agree. And if anything, this should be handled through the guest agent. Paolo
> 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 ? > Yes. > > +## > > +{ '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 No. > defined at all useful to those other OS ? > Maybe they are not. I agree that there are too Linux specific. And I did more than needed. Actually, I just want to drop the clean cache, do more than that is too heavy and no good for performance. > 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... > Agree. Thanks! Liang > 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 :|
> On Mon, Jun 13, 2016 at 11:50:08AM +0100, Daniel P. Berrange wrote: > > 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 <liang.z.li@intel.com> > > > --- > > > 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... > > Also, I'm wondering about the overall performance benefit of dropping guest > cache(s). Increasing the amount of free memory pages may have a benefit in > terms of reducing data that needs to be migrated, but it comes with a > penalty that if the guest OS needs that data, it will have to repopulate the > caches. > > If the guest is merely reading those cached pages, it isn't going to cause any > problem with chances of convergance of migration, as clean pages will be > copied only once during migration. IOW, dropping clean pages will reduce the > total memory that needs to be copied, but won't have notable affect on > convergance of live migration. Cache pages that are dirty will potentially > affect live migration convergance, if the guest OS re-dirties the pages before > they're flushed to storage. Dropping caches won't help in this respect though, > since you can't drop dirty pages. At the same time it will have a potentially > significant negative penalty on guest OS performance by forcing the guest to > re-populate the cache from slow underlying storage. I don't think there's > enough info exposed by KVM about the guest OS to be able to figure out > what kind of situation we're in wrt the guest OS cache usage. > > Based on this I think it is hard to see how a host mgmt app can make a well > informed decision about whether telling the guest OS to drop caches is a > positive thing overall. In fact I think most likely is that a mgmt app would take > a pessimistic view and not use this functionality, because there's no clearly > positive impact on migration convergance and high liklihood of negatively > impacting guest performance. > > Regards, > Daniel Thanks for your detailed analyzation. I did some test and found that drop the clean cache can speed up live migration, and drop the dirty page cache can make it slower. The reason I added more options than just the clean cache is for 'integrate', and it's too Linux specific. How about just dropping the clean page cache? is it still too Linux specific? Liang > -- > |: 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 :|
> > On 13/06/2016 12:50, Daniel P. Berrange wrote: > > 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... > > I agree. And if anything, this should be handled through the guest agent. > > Paolo Guest agent is a good choice. Thanks! Liang
* Li, Liang Z (liang.z.li@intel.com) wrote: > > 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 ? > > > Yes. > > > > +## > > > +{ '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 > > No. > > > defined at all useful to those other OS ? > > > > Maybe they are not. > I agree that there are too Linux specific. And I did more than needed. > Actually, I just want to drop the clean cache, do more than that is too heavy > and no good for performance. > > > 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... > > > > Agree. I can see an argument for giving the guest a hint about what's going on and letting the guest decide what it's going to do - so telling the guest that a migration is happening and you'd like it to make the hosts life easy seems reasonable and it doesn't make any guest OS assumptions. Dave > > Thanks! > > Liang > > 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 :| -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> * Li, Liang Z (liang.z.li@intel.com) wrote: > > > 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 ? > > > > > Yes. > > > > > > +## > > > > +{ '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 > > > > No. > > > > > defined at all useful to those other OS ? > > > > > > > Maybe they are not. > > I agree that there are too Linux specific. And I did more than needed. > > Actually, I just want to drop the clean cache, do more than that is > > too heavy and no good for performance. > > > > > 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... > > > > > > > Agree. > > I can see an argument for giving the guest a hint about what's going on and > letting the guest decide what it's going to do - so telling the guest that a > migration is happening and you'd like it to make the hosts life easy seems > reasonable and it doesn't make any guest OS assumptions. > > Dave > It seems the way I used in the previous patches is more acceptable. Thanks! Liang
> > > > +{ '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 > > > > No. > > > > > defined at all useful to those other OS ? > > > > > > > Maybe they are not. > > I agree that there are too Linux specific. And I did more than needed. > > Actually, I just want to drop the clean cache, do more than that is > > too heavy and no good for performance. > > > > > 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... > > > > > > > Agree. > > I can see an argument for giving the guest a hint about what's going on and > letting the guest decide what it's going to do - so telling the guest that a > migration is happening and you'd like it to make the hosts life easy seems > reasonable and it doesn't make any guest OS assumptions. > That's much better. Thanks! Liang
diff --git a/balloon.c b/balloon.c index 0fb34bf..3d96111 100644 --- a/balloon.c +++ b/balloon.c @@ -122,3 +122,22 @@ void qmp_balloon(int64_t target, Error **errp) trace_balloon_event(balloon_opaque, target); balloon_event_fn(balloon_opaque, target); } + +void qmp_balloon_drop_cache(DropCacheType type, Error **errp) +{ + if (!have_balloon(errp)) { + return; + } + + if (!balloon_drop_cache_fn) { + error_setg(errp, QERR_UNSUPPORTED); + return; + } + if (type < 0 && type >= DROP_CACHE_TYPE__MAX) { + error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "type", + "a value in range[0, 3]"); + return; + } + + balloon_drop_cache_fn(balloon_opaque, type); +} diff --git a/hmp-commands.hx b/hmp-commands.hx index 98b4b1a..c73572c 100644 --- a/hmp-commands.hx +++ b/hmp-commands.hx @@ -1378,6 +1378,21 @@ Request VM to change its memory allocation to @var{value} (in MB). ETEXI { + .name = "balloon_drop_cache", + .args_type = "type:s", + .params = "type", + .help = "request VM to drop its page caches", + .mhandler.cmd = hmp_balloon_drop_cache, + .command_completion = balloon_drop_cache_completion + }, + +STEXI +@item balloon_drop_cache @var{type} +@findex balloon_drop_cache +Request VM to dorp its page caches. +ETEXI + + { .name = "set_link", .args_type = "name:s,up:b", .params = "name on|off", diff --git a/hmp.c b/hmp.c index a4b1d3d..3aa1062 100644 --- a/hmp.c +++ b/hmp.c @@ -1061,6 +1061,28 @@ void hmp_balloon(Monitor *mon, const QDict *qdict) } } +void hmp_balloon_drop_cache(Monitor *mon, const QDict *qdict) +{ + const char *type = qdict_get_str(qdict, "type"); + Error *err = NULL; + int i; + + for (i = 0; i < DROP_CACHE_TYPE__MAX; i++) { + if (strcmp(type, DropCacheType_lookup[i]) == 0) { + qmp_balloon_drop_cache(1 + i, &err); + break; + } + } + + if (i == DROP_CACHE_TYPE__MAX) { + error_setg(&err, QERR_INVALID_PARAMETER, type); + } + + if (err) { + error_report_err(err); + } +} + void hmp_block_resize(Monitor *mon, const QDict *qdict) { const char *device = qdict_get_str(qdict, "device"); diff --git a/hmp.h b/hmp.h index 093d65f..6bb6499 100644 --- a/hmp.h +++ b/hmp.h @@ -55,6 +55,7 @@ void hmp_nmi(Monitor *mon, const QDict *qdict); void hmp_set_link(Monitor *mon, const QDict *qdict); void hmp_block_passwd(Monitor *mon, const QDict *qdict); void hmp_balloon(Monitor *mon, const QDict *qdict); +void hmp_balloon_drop_cache(Monitor *mon, const QDict *qdict); void hmp_block_resize(Monitor *mon, const QDict *qdict); void hmp_snapshot_blkdev(Monitor *mon, const QDict *qdict); void hmp_snapshot_blkdev_internal(Monitor *mon, const QDict *qdict); @@ -120,6 +121,8 @@ void watchdog_action_completion(ReadLineState *rs, int nb_args, const char *str); void migrate_set_capability_completion(ReadLineState *rs, int nb_args, const char *str); +void balloon_drop_cache_completion(ReadLineState *rs, int nb_args, + const char *str); void migrate_set_parameter_completion(ReadLineState *rs, int nb_args, const char *str); void host_net_add_completion(ReadLineState *rs, int nb_args, const char *str); diff --git a/monitor.c b/monitor.c index a27e115..eefdf3d 100644 --- a/monitor.c +++ b/monitor.c @@ -3367,6 +3367,24 @@ void migrate_set_parameter_completion(ReadLineState *rs, int nb_args, } } +void balloon_drop_cache_completion(ReadLineState *rs, int nb_args, + const char *str) +{ + size_t len; + + len = strlen(str); + readline_set_completion_index(rs, len); + if (nb_args == 2) { + int i; + for (i = 0; i < DROP_CACHE_TYPE__MAX; i++) { + const char *name = DropCacheType_lookup[i]; + if (!strncmp(str, name, len)) { + readline_add_completion(rs, name); + } + } + } +} + void host_net_add_completion(ReadLineState *rs, int nb_args, const char *str) { int i; 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'] } + +## +# @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'} } + +## # @Abort # # This action can be used to test transaction failure. diff --git a/qmp-commands.hx b/qmp-commands.hx index 28801a2..6650ba0 100644 --- a/qmp-commands.hx +++ b/qmp-commands.hx @@ -1802,6 +1802,29 @@ Example: EQMP { + .name = "balloon_drop_cache", + .args_type = "value:i", + .mhandler.cmd_new = qmp_marshal_balloon_drop_cache, + }, + +SQMP +balloon_drop_cache +------- + +Request VM to drop its cache. + +Arguments: + +- "value": cache type to drop (json-int) + +Example: + +-> { "execute": "balloon_drop_cache", "arguments": { "value": 1 } } +<- { "return": {} } + +EQMP + + { .name = "set_link", .args_type = "name:s,up:b", .mhandler.cmd_new = qmp_marshal_set_link,
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 <liang.z.li@intel.com> --- 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(+)