> 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 :|
��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
