>>> On 07.07.15 at 15:11, <paul.durr...@citrix.com> wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 07 July 2015 13:53 >> To: Paul Durrant >> Cc: Andrew Cooper; George Dunlap; Kevin Tian; zhiyuan...@intel.com; Zhang >> Yu; xen-devel@lists.xen.org; Keir (Xen.org) >> Subject: RE: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for >> ioreq server >> >> >>> On 07.07.15 at 11:23, <paul.durr...@citrix.com> wrote: >> > I wonder, would it be sufficient - at this stage - to add a new mapping >> > sub- >> op >> > to the HVM op to distinguish mapping of mapping gfns vs. MMIO ranges. >> That >> > way we could use the same implementation underneath for now (using >> the >> > rb_rangeset, which I think stands on its own merits for MMIO ranges >> anyway) >> >> Which would be (taking into account the good description of the >> differences between RAM and MMIO pages given by George >> yesterday [I think])? I continue to not be convinced we need >> this new rangeset type (the more that it's name seems wrong, >> since - as said by George - we're unlikely to deal with ranges >> here). >> > > I don't see that implementing rangesets on top of rb tree is a problem. IMO > it's a useful optimization in its own right since it takes something that's > currently O(n) and makes it O(log n) using an rb tree implementation that's > already there. In fact, perhaps we just make the current rangeset > implementation use rb trees underneath, then there's no need for the extra > API.
I wouldn't mind such an overall change (provided it doesn't introduce new issues), but I'm not convinced of having two rangeset implementations, and I don't see the lookup speed as an issue with the uses we have for rangesets now. The arguments for bumping the number of ranges, which would possibly affect lookup in a negative way, haven't been convincing to me so far (and XenGT isn't going to make 4.6 anyway). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
