Three Xenpaging design questions

Three Xenpaging design questions

[Gage Eads]

[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

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?

[-- Attachment #1.2: Type: text/html, Size: 1557 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Three Xenpaging design questions

[Olaf Hering]

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