xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
To: Shuai Ruan <shuai.ruan@linux.intel.com>, xen-devel@lists.xen.org
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
	ian.jackson@eu.citrix.com, Paul.Durrant@citrix.com,
	zhiyuan.lv@intel.com, jbeulich@suse.com, keir@xen.org
Subject: Re: [V9 0/3] Refactor ioreq server for better performance.
Date: Thu, 31 Dec 2015 17:32:34 +0800	[thread overview]
Message-ID: <5684F632.8020009@linux.intel.com> (raw)
In-Reply-To: <1450145110-2860-1-git-send-email-shuai.ruan@linux.intel.com>

Shuai, thank you very much for helping me push these patches!
And sorry for the delay due to my illness.
Now I'm back and will pick this up. :)

B.R.
Yu

On 12/15/2015 10:05 AM, Shuai Ruan wrote:
> From: Yu Zhang <yu.c.zhang@linux.intel.com>ng the
>
> XenGT leverages ioreq server to track and forward the accesses to
> GPU I/O resources, e.g. the PPGTT(per-process graphic translation
> tables). Currently, ioreq server uses rangeset to track the BDF/
> PIO/MMIO ranges to be emulated. To select an ioreq server, the
> rangeset is searched to see if the I/O range is recorded. However,
> traversing the link list inside rangeset could be time consuming
> when number of ranges is too high. On HSW platform, number of PPGTTs
> for each vGPU could be several hundred. On BDW, this value could
> be several thousand.  This patch series refactored rangeset to base
> it on red-back tree, so that the searching would be more efficient.
>
> Besides, this patchset also splits the tracking of MMIO and guest
> ram ranges into different rangesets. And to accommodate more ranges,
> limitation of the number of ranges in an ioreq server, MAX_NR_IO_RANGES
> is changed - future patches might be provided to tune this with other
> approaches.
>
> Changes in v9:
> 1> Change order of patch 2 and patch3.
> 2> Intruduce a const static array before hvm_ioreq_server_alloc_rangesets().
> 3> Coding style changes.
>
> Changes in v8:
> Use a clearer API name to map/unmap the write-protected memory in
> ioreq server.
>
> Changes in v7:
> 1> Coding style changes;
> 2> Fix a typo in hvm_select_ioreq_server().
>
> Changes in v6:
> Break the identical relationship between ioreq type and rangeset
> index inside ioreq server.
>
> Changes in v5:
> 1> Use gpfn, instead of gpa to track guest write-protected pages;
> 2> Remove redundant conditional statement in routine find_range().
>
> Changes in v4:
> Keep the name HVMOP_IO_RANGE_MEMORY for MMIO resources, and add
> a new one, HVMOP_IO_RANGE_WP_MEM, for write-protected memory.
>
> Changes in v3:
> 1> Use a seperate rangeset for guest ram pages in ioreq server;
> 2> Refactor rangeset, instead of introduce a new data structure.
>
> Changes in v2:
> 1> Split the original patch into 2;
> 2> Take Paul Durrant's comments:
>    a> Add a name member in the struct rb_rangeset, and use the 'q'
> debug key to dump the ranges in ioreq server;
>    b> Keep original routine names for hvm ioreq server;
>    c> Commit message changes - mention that a future patch to change
> the maximum ranges inside ioreq server.
>
>
> Yu Zhang (3):
>    Remove identical relationship between ioreq type and rangeset type.
>    Refactor rangeset structure for better performance.
>    Differentiate IO/mem resources tracked by ioreq server
>
>   tools/libxc/include/xenctrl.h    | 31 +++++++++++++++
>   tools/libxc/xc_domain.c          | 61 ++++++++++++++++++++++++++++++
>   xen/arch/x86/hvm/hvm.c           | 43 ++++++++++++++-------
>   xen/common/rangeset.c            | 82 +++++++++++++++++++++++++++++-----------
>   xen/include/asm-x86/hvm/domain.h |  4 +-
>   xen/include/public/hvm/hvm_op.h  |  1 +
>   6 files changed, 185 insertions(+), 37 deletions(-)
>

      parent reply	other threads:[~2015-12-31  9:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-15  2:05 [V9 0/3] Refactor ioreq server for better performance Shuai Ruan
2015-12-15  2:05 ` [V9 1/3] Remove identical relationship between ioreq type and rangeset type Shuai Ruan
2015-12-20  7:36   ` Tian, Kevin
2015-12-15  2:05 ` [V9 2/3] Refactor rangeset structure for better performance Shuai Ruan
2015-12-21 14:38   ` Jan Beulich
2015-12-31  9:33     ` Yu, Zhang
2016-01-06  8:53       ` Jan Beulich
2016-01-06  9:46         ` Paul Durrant
2016-01-06  9:59           ` Jan Beulich
2016-01-06 10:14             ` Paul Durrant
2015-12-15  2:05 ` [V9 3/3] Differentiate IO/mem resources tracked by ioreq server Shuai Ruan
2015-12-20  7:37   ` Tian, Kevin
2015-12-21 14:45   ` Jan Beulich
2015-12-31  9:33     ` Yu, Zhang
2016-01-06  8:59       ` Jan Beulich
2016-01-06  9:44         ` Paul Durrant
2016-01-06  9:58           ` Jan Beulich
2016-01-07  5:40             ` Yu, Zhang
2016-01-07  5:38         ` Yu, Zhang
2015-12-31  9:32 ` Yu, Zhang [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=5684F632.8020009@linux.intel.com \
    --to=yu.c.zhang@linux.intel.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=shuai.ruan@linux.intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zhiyuan.lv@intel.com \
    /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).