Re: [PATCH RFC v2 5/7] libxl/vNUMA: VM config parsing functions

[Elena Ufimtseva <ufimtseva@gmail.com>]

On Mon, Oct 14, 2013 at 9:26 AM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH RFC v2 5/7] libxl/vNUMA: VM config parsing functions"):
>> On ven, 2013-10-11 at 12:18 +0100, Ian Jackson wrote:
>> > Aren't there some constraints that need to be imposed ?  For example,
>> > distance[X,Y]==distance[Y,X] ?  What about the triangle inequality
>> > (distance[A,B] + distance[B,C] >= distance[A,C]) ?
>> >
>> I think Linux does some sanity checking of the distance table (and I
>> think it disables NUMA if finding out something weird, Elena?). However,
>> this (what Linux expects/checks for) shouldn't really be the only
>> criterion, since although Linux is the only current implementation,
>> there is no reason why this can't be implemented by other OSes.
>
> I wasn't really asking about Linux.  I was talking about NUMA systems
> in general.  The thing which prompted me to ask is simply that I want
> to be sure that the set of checks we perform has been deliberately
> chosen, to reflect the actual potential nature of NUMA systems.
>
> You have chosen to call this parameter "distance".  In mathematics, a
> distance would normally have both the symmetry and triangle
> inequality, as well as a number of other properties:
>     https://en.wikipedia.org/wiki/Metric_space#Definition
>
> What subset of those properties are true of NUMA distances ?  (I
> assume that these NUMA distances are estimates to be used by
> heuristics, rather than actual measurements of a specific underlying
> property.)

Ian, I think the distance as you say its not a geometrical distance.
In that case, I am not even sure if that triangle inequality should hold.
I may be wrong.
And NUMA distance is something that vendor defines.

>
>> > If we do need this I think the nested lists are probably a better
>> > syntax for specifying the whole array.
>>
>> Agreed. I actually wanted to say the same. Would something like this be
>> ok?
>>
>> distances = [ [10, 20], [20, 10] ]
>
> Right.  I don't think there is anything preventing us implementing
> this in the parser, although the existing code probably doesn't
> support it.  I can help with the parser.

Sure, that would be great! Id like to work on this too, but the timing may not
permit it untill end of October.

>
> ...
>> distances = [ [10, 20, 30, 40],
>>                   [10, 20, 30],
>>                       [10, 20],
>>                           [10] ]
>>
>> (I.e., "distances = [ [10, 20, 30, 40], [10, 20, 30], [10, 20], [10] ])
>
> I'd suggest that we should expect the user to specify the lower left
> half, rather than the upper right.  That avoids the counterintuitive
> offset of the indices in subsequent rows.
>
> (Also I observe that your example violates distance[A,B] == 0.)
>
> Ian.



-- 
Elena