Hi, I''ve been fiddling with the xenpaging source recently, and I have a few questions regarding it. 1. file_op() vs. pread() and pwrite(): is there any reason file_op is used instead of pread and pwrite? Just curious. 2. Separation of policy and mechanism: I appreciate that the logic for selecting victim pages is separated from the eviction mechanism. However the policy abstraction is somewhat broken in two ways: policy_notify_paged_in_nomru() exposes the use of an mru list, and xenpaging_resume_page() contains logic that decides whether to add the gfn to the mru list. The mru list is a policy detail that shouldn''t be exposed to the mechanism layer (even if the mru list doesn''t actually influence default policy''s decisions, as is currently the case). I bring this up because I''d like to experiment with different policies. Are there any reasons (or flaws in my reasoning) why I shouldn''t fix the identified issues with the policy abstractoin? 3. memory/target-tot_pages: from the name, one would assume this value sets a limit of the number of memory pages in a VM. Specifically, the number of 4 KB pages in the VM. Instead, target-tot_pages is a memory limit in KiB. I found this fairly misleading, but perhaps I am in the minority. Is there any interest in either renaming this value or removing the KiB to pages conversion so that its behavior more accurately reflects its name? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, Oct 02, Gage Eads wrote:> 1. file_op() vs. pread() and pwrite(): is there any reason file_op is used > instead of pread and pwrite? Just curious.Maybe the original author was not aware of them? If there is a benefit to switch, submit a patch.> I bring this up because I''d like to experiment with different policies. Are > there any reasons (or flaws in my reasoning) why I shouldn''t fix the identified > issues with the policy abstractoin?This depends one the workload within the guest. IMO its not predictable what pages a guest will touch in the future, so any choice done by xenpaging is good. One thing that was suggested is to track the guest page tables and skip such gfns.> 3. memory/target-tot_pages: from the name, one would assume this value sets a > limit of the number of memory pages in a VM. Specifically, the number of 4 KB > pages in the VM. Instead, target-tot_pages is a memory limit in KiB. I found > this fairly misleading, but perhaps I am in the minority. Is there any interest > in either renaming this value or removing the KiB to pages conversion so that > its behavior more accurately reflects its name?This property tries to follow other memory properties like maxmem. But the whole logic may not be consistent. Since this property is not used by the tools yet, we can likely change it until libxl gets a better guest memory handling. Maybe such property should describe an amount of memory like "888MB". Olaf