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(-)
>
prev 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).