| 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 :|
PiBPbiBNb24sIEp1biAxMywgMjAxNiBhdCAxMTo1MDowOEFNICswMTAwLCBEYW5pZWwgUC4gQmVy cmFuZ2Ugd3JvdGU6DQo+ID4gT24gTW9uLCBKdW4gMTMsIDIwMTYgYXQgMDY6MTY6NDVQTSArMDgw MCwgTGlhbmcgTGkgd3JvdGU6DQo+ID4gPiBBZGQgdGhlIGhtcCBhbmQgcW1wIGludGVyZmFjZSB0 byBkcm9wIHZtJ3MgcGFnZSBjYWNoZSwgdXNlcnMgY2FuDQo+ID4gPiBjb250cm9sIHRoZSB0eXBl IG9mIGNhY2hlIHRoZXkgd2FudCB2bSB0byBkcm9wLg0KPiA+ID4NCj4gPiA+IFNpZ25lZC1vZmYt Ynk6IExpYW5nIExpIDxsaWFuZy56LmxpQGludGVsLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gIGJh bGxvb24uYyAgICAgICAgfCAxOSArKysrKysrKysrKysrKysrKysrDQo+ID4gPiAgaG1wLWNvbW1h bmRzLmh4ICB8IDE1ICsrKysrKysrKysrKysrKw0KPiA+ID4gIGhtcC5jICAgICAgICAgICAgfCAy MiArKysrKysrKysrKysrKysrKysrKysrDQo+ID4gPiAgaG1wLmggICAgICAgICAgICB8ICAzICsr Kw0KPiA+ID4gIG1vbml0b3IuYyAgICAgICAgfCAxOCArKysrKysrKysrKysrKysrKysNCj4gPiA+ ICBxYXBpLXNjaGVtYS5qc29uIHwgMzUgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysNCj4gPiA+ICBxbXAtY29tbWFuZHMuaHggIHwgMjMgKysrKysrKysrKysrKysrKysrKysrKysN Cj4gPiA+ICA3IGZpbGVzIGNoYW5nZWQsIDEzNSBpbnNlcnRpb25zKCspDQo+ID4NCj4gPiA+IGRp ZmYgLS1naXQgYS9xYXBpLXNjaGVtYS5qc29uIGIvcWFwaS1zY2hlbWEuanNvbiBpbmRleA0KPiA+ ID4gODQ4M2JkZi4uMTE3ZjcwYSAxMDA2NDQNCj4gPiA+IC0tLSBhL3FhcGktc2NoZW1hLmpzb24N Cj4gPiA+ICsrKyBiL3FhcGktc2NoZW1hLmpzb24NCj4gPiA+IEBAIC0xNjU1LDYgKzE2NTUsNDEg QEANCj4gPiA+ICB7ICdjb21tYW5kJzogJ2JhbGxvb24nLCAnZGF0YSc6IHsndmFsdWUnOiAnaW50 J30gfQ0KPiA+ID4NCj4gPiA+ICAjIw0KPiA+ID4gKyMgQERyb3BDYWNoZVR5cGUNCj4gPiA+ICsj DQo+ID4gPiArIyBDYWNoZSB0eXBlcyBlbnVtZXJhdGlvbg0KPiA+ID4gKyMNCj4gPiA+ICsjIEBj bGVhbjogRHJvcCB0aGUgY2xlYW4gcGFnZSBjYWNoZS4NCj4gPiA+ICsjDQo+ID4gPiArIyBAc2xh YjogRHJvcCB0aGUgc2xhYiBjYWNoZS4NCj4gPiA+ICsjDQo+ID4gPiArIyBAYWxsOiBEcm9wIGJv dGggdGhlIGNsZWFuIGFuZCB0aGUgc2xhYiBjYWNoZS4NCj4gPiA+ICsjDQo+ID4gPiArIyBTaW5j ZTogMi43DQo+ID4gPiArIyMNCj4gPiA+ICt7ICdlbnVtJzogJ0Ryb3BDYWNoZVR5cGUnLCAnZGF0 YSc6IFsnY2xlYW4nLCAnc2xhYicsICdhbGwnXSB9DQo+ID4NCj4gPiBQcmVzdW1hYmx5IHRoZXNl IGNvbnN0YW50cyBhcmUgY29ycmVzcG9uZGluZyB0byB0aGUgMyBvcHRpb25zIGZvcg0KPiA+IHZt LmRyb3BfY2FjaGVzIHN5c2N0bCBrbm9iDQo+ID4NCj4gPiBbcXVvdGVdDQo+ID4gVG8gZnJlZSBw YWdlY2FjaGUsIHVzZToNCj4gPg0KPiA+ICAgZWNobyAxID4gL3Byb2Mvc3lzL3ZtL2Ryb3BfY2Fj aGVzDQo+ID4NCj4gPiBUbyBmcmVlIGRlbnRyaWVzIGFuZCBpbm9kZXMsIHVzZToNCj4gPg0KPiA+ ICAgZWNobyAyID4gL3Byb2Mvc3lzL3ZtL2Ryb3BfY2FjaGVzDQo+ID4NCj4gPiBUbyBmcmVlIHBh Z2VjYWNoZSwgZGVudHJpZXMgYW5kIGlub2RlcywgdXNlOg0KPiA+DQo+ID4gICBlY2hvIDMgPiAv cHJvYy9zeXMvdm0vZHJvcF9jYWNoZXMNCj4gPg0KPiA+IEJlY2F1c2Ugd3JpdGluZyB0byB0aGlz IGZpbGUgaXMgYSBub25kZXN0cnVjdGl2ZSBvcGVyYXRpb24gYW5kIGRpcnR5DQo+ID4gb2JqZWN0 cyBhcmUgbm90IGZyZWVhYmxlLCB0aGUgdXNlciBzaG91bGQgcnVuIHN5bmMoMSkgZmlyc3QuDQo+ ID4gWy9xdW90ZV0NCj4gPg0KPiA+IElPVywgYnkgJ3NsYWInIHlvdSBtZWFuIGRlbnRyaWVzIGFu ZCBpbm9kZXMgPw0KPiA+DQo+ID4gPiArDQo+ID4gPiArIyMNCj4gPiA+ICsjIEBiYWxsb29uX2Ry b3BfY2FjaGU6DQo+ID4gPiArIw0KPiA+ID4gKyMgUmVxdWVzdCB0aGUgdm0gdG8gZHJvcCBpdHMg Y2FjaGUuDQo+ID4gPiArIw0KPiA+ID4gKyMgQHZhbHVlOiB0aGUgdHlwZSBvZiBjYWNoZSB3YW50 IHZtIHRvIGRyb3AgIyAjIFJldHVybnM6IE5vdGhpbmcgb24NCj4gPiA+ICtzdWNjZXNzDQo+ID4g PiArIyAgICAgICAgICBJZiB0aGUgYmFsbG9vbiBkcml2ZXIgaXMgZW5hYmxlZCBidXQgbm90IGZ1 bmN0aW9uYWwgYmVjYXVzZSB0aGUNCj4gS1ZNDQo+ID4gPiArIyAgICAgICAgICAgIGtlcm5lbCBt b2R1bGUgY2Fubm90IHN1cHBvcnQgaXQsIEt2bU1pc3NpbmdDYXANCj4gPiA+ICsjICAgICAgICAg IElmIG5vIGJhbGxvb24gZGV2aWNlIGlzIHByZXNlbnQsIERldmljZU5vdEFjdGl2ZQ0KPiA+ID4g KyMNCj4gPiA+ICsjIE5vdGVzOiBUaGlzIGNvbW1hbmQganVzdCBpc3N1ZXMgYSByZXF1ZXN0IHRv IHRoZSBndWVzdC4gIFdoZW4gaXQNCj4gcmV0dXJucywNCj4gPiA+ICsjICAgICAgICB0aGUgZHJv cCBjYWNoZSBvcGVyYXRpb24gbWF5IG5vdCBoYXZlIGNvbXBsZXRlZC4gIEEgZ3Vlc3QgY2FuDQo+ IGRyb3AgaXRzDQo+ID4gPiArIyAgICAgICAgY2FjaGUgaW5kZXBlbmRlbnQgb2YgdGhpcyBjb21t YW5kLg0KPiA+ID4gKyMNCj4gPiA+ICsjIFNpbmNlOiAyLjcuMA0KPiA+ID4gKyMjDQo+ID4gPiAr eyAnY29tbWFuZCc6ICdiYWxsb29uX2Ryb3BfY2FjaGUnLCAnZGF0YSc6IHsndmFsdWUnOg0KPiA+ ID4gKydEcm9wQ2FjaGVUeXBlJ30gfQ0KPiA+DQo+ID4gQWxzbywgYXMgbm90ZWQgaW4gdGhlIG1h biBwYWdlIHF1b3RlIGFib3ZlLCBpdCBpcyByZWNvbW1lbmRlZCB0byBjYWxsDQo+ID4gc3luYygp IHRvIG1pbmltaXNlIGRpcnR5IHBhZ2VzLiBTaG91bGQgd2UgaGF2ZSBhIHdheSB0byByZXF1ZXN0 IGEgc3luYw0KPiA+IGFzIHBhcnQgb2YgdGhpcyBtb25pdG9yIGNvbW1hbmQuDQo+ID4NCj4gPiBN b3JlIGdlbmVyYWxseSwgaXQgZmVlbHMgbGlrZSB0aGlzIGlzIHRha2luZyBhcyBkb3duIGEgcGF0 aCB0b3dhcmRzDQo+ID4gYWN0aXZlbHkgbWFuYWdpbmcgdGhlIGd1ZXN0IGtlcm5lbCBWTSBmcm9t IHRoZSBob3N0LiBJcyB0aGlzIHJlYWxseSBhDQo+ID4gcGF0aCB3ZSB3YW50IHRvIGJlIGdvaW5n IGRvd24sIGdpdmVuIHRoYXQgaXRzIGdvaW5nIHRvIHRha2UgdXMgaW50bw0KPiA+IGluY3JlYXNp bmcgbm9uLXBvcnRhYmxlIGNvbmNlcHRzIHdoaWNoIGFyZSBwb3RlbnRpYWxseSBkaWZmZXJlbnQg Zm9yDQo+ID4gZWFjaCBndWVzdCBPUyBrZXJuZWwuICBJcyB0aGlzIGRyb3AgY2FjaGVzIGZlYXR1 cmUgYXQgYWxsIGFwcGxpY2FibGUNCj4gPiB0byBXaW5kb3dzLCBPUy1YLCAqQlNEIGd1ZXN0IE9T IGltcGxzIG9mIHRoZSBiYWxsb29uIGRyaXZlciA/IElmIGl0IGlzDQo+ID4gYXBwbGljYWJsZSwg YXJlIHRoZSAzIGZpeGVkIGNvbnN0YW50cyB5b3UndmUgZGVmaW5lZCBhdCBhbGwgdXNlZnVsIHRv DQo+ID4gdGhvc2Ugb3RoZXIgT1MgPw0KPiA+DQo+ID4gSSdtIHdhcnlpbmcgb2YgdXMgdGFraW5n IGEgZGVzaWduIHBhdGggd2hpY2ggaXMgc28gTGludXggc3BlY2lmaWMgaXQNCj4gPiBpc24ndCB1 c2VmdWwgZWxzZXdoZXJlLiBJT1csIGp1c3QgYmVjYXVzZSB3ZSBjYW4gZG8gdGhpcywgZG9lc24n dCBtZWFuDQo+ID4gd2Ugc2hvdWxkIGRvIHRoaXMuLi4NCj4gDQo+IEFsc28sIEknbSB3b25kZXJp bmcgYWJvdXQgdGhlIG92ZXJhbGwgcGVyZm9ybWFuY2UgYmVuZWZpdCBvZiBkcm9wcGluZyBndWVz dA0KPiBjYWNoZShzKS4gSW5jcmVhc2luZyB0aGUgYW1vdW50IG9mIGZyZWUgbWVtb3J5IHBhZ2Vz IG1heSBoYXZlIGEgYmVuZWZpdCBpbg0KPiB0ZXJtcyBvZiByZWR1Y2luZyBkYXRhIHRoYXQgbmVl ZHMgdG8gYmUgbWlncmF0ZWQsIGJ1dCBpdCBjb21lcyB3aXRoIGENCj4gcGVuYWx0eSB0aGF0IGlm IHRoZSBndWVzdCBPUyBuZWVkcyB0aGF0IGRhdGEsIGl0IHdpbGwgaGF2ZSB0byByZXBvcHVsYXRl IHRoZQ0KPiBjYWNoZXMuDQo+IA0KPiBJZiB0aGUgZ3Vlc3QgaXMgbWVyZWx5IHJlYWRpbmcgdGhv c2UgY2FjaGVkIHBhZ2VzLCBpdCBpc24ndCBnb2luZyB0byBjYXVzZSBhbnkNCj4gcHJvYmxlbSB3 aXRoIGNoYW5jZXMgb2YgY29udmVyZ2FuY2Ugb2YgbWlncmF0aW9uLCBhcyBjbGVhbiBwYWdlcyB3 aWxsIGJlDQo+IGNvcGllZCBvbmx5IG9uY2UgZHVyaW5nIG1pZ3JhdGlvbi4gSU9XLCBkcm9wcGlu ZyBjbGVhbiBwYWdlcyB3aWxsIHJlZHVjZSB0aGUNCj4gdG90YWwgbWVtb3J5IHRoYXQgbmVlZHMg dG8gYmUgY29waWVkLCBidXQgd29uJ3QgaGF2ZSBub3RhYmxlIGFmZmVjdCBvbg0KPiBjb252ZXJn YW5jZSBvZiBsaXZlIG1pZ3JhdGlvbi4gQ2FjaGUgcGFnZXMgdGhhdCBhcmUgZGlydHkgd2lsbCBw b3RlbnRpYWxseQ0KPiBhZmZlY3QgbGl2ZSBtaWdyYXRpb24gY29udmVyZ2FuY2UsIGlmIHRoZSBn dWVzdCBPUyByZS1kaXJ0aWVzIHRoZSBwYWdlcyBiZWZvcmUNCj4gdGhleSdyZSBmbHVzaGVkIHRv IHN0b3JhZ2UuIERyb3BwaW5nIGNhY2hlcyB3b24ndCBoZWxwIGluIHRoaXMgcmVzcGVjdCB0aG91 Z2gsDQo+IHNpbmNlIHlvdSBjYW4ndCBkcm9wIGRpcnR5IHBhZ2VzLiBBdCB0aGUgc2FtZSB0aW1l IGl0IHdpbGwgaGF2ZSBhIHBvdGVudGlhbGx5DQo+IHNpZ25pZmljYW50IG5lZ2F0aXZlIHBlbmFs dHkgb24gZ3Vlc3QgT1MgcGVyZm9ybWFuY2UgYnkgZm9yY2luZyB0aGUgZ3Vlc3QgdG8NCj4gcmUt cG9wdWxhdGUgdGhlIGNhY2hlIGZyb20gc2xvdyB1bmRlcmx5aW5nIHN0b3JhZ2UuICBJIGRvbid0 IHRoaW5rIHRoZXJlJ3MNCj4gZW5vdWdoIGluZm8gZXhwb3NlZCBieSBLVk0gYWJvdXQgdGhlIGd1 ZXN0IE9TIHRvIGJlIGFibGUgdG8gZmlndXJlIG91dA0KPiB3aGF0IGtpbmQgb2Ygc2l0dWF0aW9u IHdlJ3JlIGluIHdydCB0aGUgZ3Vlc3QgT1MgY2FjaGUgdXNhZ2UuDQo+IA0KPiBCYXNlZCBvbiB0 aGlzIEkgdGhpbmsgaXQgaXMgaGFyZCB0byBzZWUgaG93IGEgaG9zdCBtZ210IGFwcCBjYW4gbWFr ZSBhIHdlbGwNCj4gaW5mb3JtZWQgZGVjaXNpb24gYWJvdXQgd2hldGhlciB0ZWxsaW5nIHRoZSBn dWVzdCBPUyB0byBkcm9wIGNhY2hlcyBpcyBhDQo+IHBvc2l0aXZlIHRoaW5nIG92ZXJhbGwuIElu IGZhY3QgSSB0aGluayBtb3N0IGxpa2VseSBpcyB0aGF0IGEgbWdtdCBhcHAgd291bGQgdGFrZQ0K PiBhIHBlc3NpbWlzdGljIHZpZXcgYW5kIG5vdCB1c2UgdGhpcyBmdW5jdGlvbmFsaXR5LCBiZWNh dXNlIHRoZXJlJ3Mgbm8gY2xlYXJseQ0KPiBwb3NpdGl2ZSBpbXBhY3Qgb24gbWlncmF0aW9uIGNv bnZlcmdhbmNlIGFuZCBoaWdoIGxpa2xpaG9vZCBvZiBuZWdhdGl2ZWx5DQo+IGltcGFjdGluZyBn dWVzdCBwZXJmb3JtYW5jZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IERhbmllbA0KDQpUaGFua3MgZm9y IHlvdXIgZGV0YWlsZWQgYW5hbHl6YXRpb24uDQpJIGRpZCBzb21lIHRlc3QgYW5kIGZvdW5kIHRo YXQgZHJvcCB0aGUgY2xlYW4gY2FjaGUgY2FuIHNwZWVkIHVwIGxpdmUgbWlncmF0aW9uLCANCmFu ZCBkcm9wIHRoZSBkaXJ0eSBwYWdlIGNhY2hlIGNhbiBtYWtlIGl0IHNsb3dlci4NClRoZSByZWFz b24gSSBhZGRlZCBtb3JlIG9wdGlvbnMgdGhhbiBqdXN0IHRoZSBjbGVhbiBjYWNoZSBpcyBmb3Ig J2ludGVncmF0ZScsIGFuZA0KaXQncyB0b28gIExpbnV4IHNwZWNpZmljLiANCg0KSG93IGFib3V0 IGp1c3QgZHJvcHBpbmcgdGhlIGNsZWFuIHBhZ2UgY2FjaGU/IGlzIGl0IHN0aWxsIHRvbyBMaW51 eCBzcGVjaWZpYz8NCg0KTGlhbmcNCg0KPiAtLQ0KPiB8OiBodHRwOi8vYmVycmFuZ2UuY29tICAg ICAgLW8tICAgIGh0dHA6Ly93d3cuZmxpY2tyLmNvbS9waG90b3MvZGJlcnJhbmdlLyA6fA0KPiB8 OiBodHRwOi8vbGlidmlydC5vcmcgICAgICAgICAgICAgIC1vLSAgICAgICAgICAgICBodHRwOi8v dmlydC1tYW5hZ2VyLm9yZyA6fA0KPiB8OiBodHRwOi8vYXV0b2J1aWxkLm9yZyAgICAgICAtby0g ICAgICAgICBodHRwOi8vc2VhcmNoLmNwYW4ub3JnL35kYW5iZXJyLyA6fA0KPiB8OiBodHRwOi8v ZW50YW5nbGUtcGhvdG8ub3JnICAgICAgIC1vLSAgICAgICBodHRwOi8vbGl2ZS5nbm9tZS5vcmcv Z3RrLXZuYyA6fA0K -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PiANCj4gT24gMTMvMDYvMjAxNiAxMjo1MCwgRGFuaWVsIFAuIEJlcnJhbmdlIHdyb3RlOg0KPiA+ IE1vcmUgZ2VuZXJhbGx5LCBpdCBmZWVscyBsaWtlIHRoaXMgaXMgdGFraW5nIGFzIGRvd24gYSBw YXRoIHRvd2FyZHMNCj4gPiBhY3RpdmVseSBtYW5hZ2luZyB0aGUgZ3Vlc3Qga2VybmVsIFZNIGZy b20gdGhlIGhvc3QuIElzIHRoaXMgcmVhbGx5IGENCj4gPiBwYXRoIHdlIHdhbnQgdG8gYmUgZ29p bmcgZG93biwgZ2l2ZW4gdGhhdCBpdHMgZ29pbmcgdG8gdGFrZSB1cyBpbnRvDQo+ID4gaW5jcmVh c2luZyBub24tcG9ydGFibGUgY29uY2VwdHMgd2hpY2ggYXJlIHBvdGVudGlhbGx5IGRpZmZlcmVu dCBmb3INCj4gPiBlYWNoIGd1ZXN0IE9TIGtlcm5lbC4gIElzIHRoaXMgZHJvcCBjYWNoZXMgZmVh dHVyZSBhdCBhbGwgYXBwbGljYWJsZQ0KPiA+IHRvIFdpbmRvd3MsIE9TLVgsICpCU0QgZ3Vlc3Qg T1MgaW1wbHMgb2YgdGhlIGJhbGxvb24gZHJpdmVyID8gSWYgaXQgaXMNCj4gPiBhcHBsaWNhYmxl LCBhcmUgdGhlIDMgZml4ZWQgY29uc3RhbnRzIHlvdSd2ZSBkZWZpbmVkIGF0IGFsbCB1c2VmdWwg dG8NCj4gPiB0aG9zZSBvdGhlciBPUyA/DQo+ID4NCj4gPiBJJ20gd2FyeWluZyBvZiB1cyB0YWtp bmcgYSBkZXNpZ24gcGF0aCB3aGljaCBpcyBzbyBMaW51eCBzcGVjaWZpYyBpdA0KPiA+IGlzbid0 IHVzZWZ1bCBlbHNld2hlcmUuIElPVywganVzdCBiZWNhdXNlIHdlIGNhbiBkbyB0aGlzLCBkb2Vz bid0IG1lYW4NCj4gPiB3ZSBzaG91bGQgZG8gdGhpcy4uLg0KPiANCj4gSSBhZ3JlZS4gIEFuZCBp ZiBhbnl0aGluZywgdGhpcyBzaG91bGQgYmUgaGFuZGxlZCB0aHJvdWdoIHRoZSBndWVzdCBhZ2Vu dC4NCj4gDQo+IFBhb2xvDQoNCkd1ZXN0IGFnZW50IGlzIGEgZ29vZCBjaG9pY2UuIFRoYW5rcyEN Cg0KTGlhbmcNCgkNCg0K -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> * 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > +{ '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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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(+)