Re: [Xen-devel] [PATCH v2 1/2] Resize the MAX_NR_IO_RANGES for ioreq server

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.07.15 at 15:11, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 07 July 2015 13:53
>> To: Paul Durrant
>> Cc: Andrew Cooper; George Dunlap; Kevin Tian; zhiyuan.lv@xxxxxxxxx; Zhang
>> Yu; xen-devel@xxxxxxxxxxxxx; 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.Durrant@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel