All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.