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
next prev parent 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).