On Wed, 1 Dec 2010 12:10:43 +0530 Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: > > That's a point. Then, why the guest has to do _extra_ work for host even when > > the host says nothing ? I think trigger this by guests themselves is not very good. > > I've mentioned it before, the guest keeping free memory without a > large performance hit, helps, the balloon driver is able to quickly > retrieve this memory if required or the guest can use this memory for > some other application/task. > The cached data is mostly already present in the host page cache. Why ? Are there parameters/stats which shows this is _true_ ? How we can guarantee/show it to users ? Please add an interface to show "shared rate between guest/host" If not, any admin will not turn this on because "file cache status on host" is a black box for guest admins. I think this patch skips something important steps. 2nd point is maybe for reducing total host memory usage and for increasing the number of guests on a host. For that, this feature is useful only when all guests on a host are friendly and devoted to the health of host memory management because all setting must be done in the guest. This can be passed as even by qemu's command line argument. And _no_ benefit for the guests who reduce it's resource to help host management because there is no guarantee dropped caches are on host memory. So, for both claim, I want to see an interface to show the number of shared pages between hosts and guests rather than imagine it. BTW, I don't like this kind of "please give us your victim, please please please" logic. The host should be able to "steal" what it wants in force. Then, I think there should be no On/Off visible interfaces. The vm firmware should tell to turn on this if administrator of the host wants. BTW2, please test with some other benchmarks (which read file caches.) I don't think kernel make is good test for this. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
