xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Zhang Yu <yu.c.zhang@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Shuai Ruan <shuai.ruan@linux.intel.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@citrix.com>,
	"zhiyuan.lv@intel.com" <zhiyuan.lv@intel.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>
Subject: Re: [V9 2/3] Refactor rangeset structure for better performance.
Date: Wed, 6 Jan 2016 09:46:38 +0000	[thread overview]
Message-ID: <03002f0a0e6448ad912f650334facf15@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <568CE40E02000078000C3CDE@prv-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 06 January 2016 08:53
> To: Zhang Yu
> Cc: Andrew Cooper; Paul Durrant; Wei Liu; Ian Jackson; Stefano Stabellini;
> Kevin Tian; zhiyuan.lv@intel.com; Shuai Ruan; xen-devel@lists.xen.org; Keir
> (Xen.org)
> Subject: Re: [Xen-devel] [V9 2/3] Refactor rangeset structure for better
> performance.
> 
> >>> On 31.12.15 at 10:33, <yu.c.zhang@linux.intel.com> wrote:
> > On 12/21/2015 10:38 PM, Jan Beulich wrote:
> >>>>> On 15.12.15 at 03:05, <shuai.ruan@linux.intel.com> wrote:
> >>> This patch refactors struct rangeset to base it on the red-black
> >>> tree structure, instead of on the current doubly linked list. By
> >>> now, ioreq leverages rangeset to keep track of the IO/memory
> >>> resources to be emulated. Yet when number of ranges inside one
> >>> ioreq server is very high, traversing a doubly linked list could
> >>> be time consuming. With this patch, the time complexity for
> >>> searching a rangeset can be improved from O(n) to O(log(n)).
> >>> Interfaces of rangeset still remain the same, and no new APIs
> >>> introduced.
> >>
> >> So this indeed addresses one of the two original concerns. But
> >> what about the other (resource use due to thousands of ranges
> >> in use by a single VM)? IOW I'm still unconvinced this is the way
> >> to go.
> >
> > Thank you, Jan. As you saw in patch 3/3, the other concern was solved
> > by extending the rangeset size, which may not be convictive for you.
> > But I believe this patch - refactoring the rangeset to rb_tree, does
> > not only solve XenGT's performance issue, but may also be helpful in
> > the future, e.g. if someday the rangeset is not allocated in xen heap
> > and can have a great number of ranges in it. :)
> 
> I don't follow: Patch 3 makes things worse resource consumption
> wise, not better.
> 

Yes, it allows the rangeset to grow larger. Would it be better to tie emulation rangesets to a specific domain and have the rangeset limits defined for the domain by the toolstack?

  Paul

> Jan

  reply	other threads:[~2016-01-06  9:46 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 [this message]
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 ` [V9 0/3] Refactor ioreq server for better performance Yu, Zhang

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=03002f0a0e6448ad912f650334facf15@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Stefano.Stabellini@citrix.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=shuai.ruan@linux.intel.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yu.c.zhang@linux.intel.com \
    --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).