Re: [PATCH v3 1/2] Fix nodeinfo output on PPC64 KVM hosts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2015-07-06 at 17:34 +0530, Shivaprasad bhat wrote:
> 
> I had a chance to
> test the patch and it
> seems to work consistently in all sucores_per_core modes.

Hi Shivaprasad,

while reworking the series to address Martin's comments, I have created
a couple more test cases and I've run into a situation I'm not sure how
to handle.

Suppose we have the following situation on the host:

     0*   1    2    3    4    5    6    7  
     8*   9   10   11   12   13   14   15  
    16*  17*  18*  19*  20   21   22   23  
    24*  25   26   27   28   29   30   31  
    32*  33   34   35   36   37   38   39  
    40*  41   42   43   44   45   46   47  
    48   49   50   51   52   53   54   55  
    56   57   58   59   60   61   62   63  
    64   65   66   67   68   69   70*  71  
    72*  73   74   75   76   77   78   79  
    80*  81   82   83   84   85   86   87  
    88*  89*  90*  91*  92*  93*  94*  95* 

Basically the user has *really* messed up its configuration :)

Nodes 0 (CPUs 0-23), 2 (CPUs 48-71) and 3 (CPUs 72-95) are easy: in all
cases at least one of the secondary threads is online, so we should
fallback to the subcore-unaware logic and just count the online CPUs.

Node 1 (CPUs 24-47) is different, though: all the primary threads are
online, and all the secondary threads are offline, just like they're
supposed to.

How should the threads in node 1 be counted, then? Should the
subcore-aware logic be applied (resulting in 41 online CPUs overall) or
should we use the fallback logic for all nodes because at least one of
them is violating our expectations (resulting in 20 online CPUs
overall)?

I'm tending towards "it doesn't really matter", eg. if you mess with
the configuration you can't expect the reported capacity to make any
sense. I'd probably go with the former option (because it requires less
changes to the code) and add a paragraph about it to the documentation,
but I'd love to hear your opinion on the subject.

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]