xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Olaf Hering <olaf@aepfle.de>
To: Gage Eads <geads@eecs.berkeley.edu>
Cc: xen-devel@lists.xen.org
Subject: Re: Three Xenpaging design questions
Date: Fri, 4 Oct 2013 10:42:09 +0200	[thread overview]
Message-ID: <20131004084209.GB30604@aepfle.de> (raw)
In-Reply-To: <CAKMCW7GoR20fO0nT4DT+taAHBuzXT14SdoNz8263nA1UmCjWLg@mail.gmail.com>

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

      reply	other threads:[~2013-10-04  8:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03  0:40 Three Xenpaging design questions Gage Eads
2013-10-04  8:42 ` Olaf Hering [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131004084209.GB30604@aepfle.de \
    --to=olaf@aepfle.de \
    --cc=geads@eecs.berkeley.edu \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).