Thank you for your kind reply, George.
I am interested on the PoD memory. In my perspective, PoD mainly works in the system initialization stage. Before the balloon driver begins to work, it can limit the memory consumption of the guests. However, after a while the guest OS will commit more memory, but PoD cannot reclaim any more at that time even when the committed pages is IO cache. While the balloon keeps work all of the time.
Would you please tell me whether my thought is correct?
Actually, in my opinion, the guest IO cache is mostly useless, since the Dom0 will cache the IO operations. Such a double-cache wastes the memory resources. Is there any good idea for that like Transcendent Memory while works with HVM?
在 2010年11月16日 下午8:56，George Dunlap <dunlapg@xxxxxxxxx>
2010/11/16 牛立新 <topperxin@xxxxxxx>:
> o, it's strange, the old version have no this limitation.No; unfortunately a great deal of functionality present in "classic
xen" has been lost in the process of getting the core dom0 support
into the pvops kernel. I think the plan is, once we have the
necessary changes to non-xen code pushed up stream, we can start
working on getting feature parity with classic xen.
> At 2010-11-16 19:35:50，"Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx
>>On Tue, 16 Nov 2010, Chu Rui wrote:
>>> I have noticed that, in the code of linux/drivers/xen/balloon.c, there exists the snippet as this:
>>> static int __init balloon_init(void)
>>> unsigned long pfn;
>>> struct page *page;
>>> if (!xen_pv_domain())
>>> return -ENODEV;
>>> Does it means the driver will not work in HVM? If so, where is the HVN-enabled code for that?
>>not yet, even though I have a patch ready to enable it:
> 网易163/126邮箱百分百兼容iphone ipad邮件收发
> Xen-devel mailing list
Xen-devel mailing list