[ovirt-devel] [vdsm] strange network test failure on FC23

Nir Soffer nsoffer at redhat.com
Sun Nov 29 16:34:32 UTC 2015


On Sun, Nov 29, 2015 at 6:01 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
> On Sun, Nov 29, 2015 at 5:37 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>>
>> On Sun, Nov 29, 2015 at 10:37 AM, Yaniv Kaul <ykaul at redhat.com> wrote:
>> >
>> > On Fri, Nov 27, 2015 at 6:55 PM, Francesco Romani <fromani at redhat.com>
>> > wrote:
>> >>
>> >> Using taskset, the ip command now takes a little longer to complete.
>> >
>> >
>> > Since we always use the same set of CPUs, I assume using a mask (for 0
&
>> > 1,
>> > just use 0x3, as the man suggests) might be a tiny of a fraction faster
>> > to
>> > execute taskset with, instead of the need to translate the numeric CPU
>> > list.
>>
>> Creating the string "0-<last cpu index>" is one line in vdsm. The code
>> handling this in
>> taskset is written in C, so the parsing time is practically zero. Even
>> if it was non-zero,
>> this code run once when we run a child process, so the cost is
>> insignificant.
>
>
> I think it's easier to just to have it as a mask in a config item
somewhere,
> without need to create it or parse it anywhere.
> For us and for the user.

We have this option in /etc/vdsm/vdsm.conf:

    # Comma separated whitelist of CPU cores on which VDSM is allowed to
    # run. The default is "", meaning VDSM can be scheduled by  the OS to
    # run on any core. Valid examples: "1", "0,1", "0,2,3"
    # cpu_affinity = 1

I think this is the easiest option for users.

>> > However, the real concern is making sure CPUs 0 & 1 are not really too
>> > busy
>> > with stuff (including interrupt handling, etc.)
>>
>> This code is used when we run a child process, to allow the child
>> process to run on
>> all cpus (in this case, cpu 0 and cpu 1). So I think there is no concern
>> here.
>>
>> Vdsm itself is running by default on cpu 1, which should be less busy
>> then cpu 0.
>
>
> I assume those are cores, which probably in a multi-socket will be in the
> first socket only.
> There's a good chance that the FC and or network/cards will also bind
their
> interrupts to core0 & core 1 (check /proc/interrupts) on the same socket.
> From my poor laptop (1s, 4c):
> 42:    1487104       9329       4042       3598  IR-PCI-MSI 512000-edge

> 0000:00:1f.2
>
> (my SATA controller)
>
> 43:   14664923         34         18         13  IR-PCI-MSI 327680-edge

> xhci_hcd
> (my dock station connector)
>
> 45:    6754579       4437       2501       2419  IR-PCI-MSI 32768-edge
> i915
> (GPU)
>
> 47:     187409      11627       1235       1259  IR-PCI-MSI 2097152-edge

> iwlwifi
> (NIC, wifi)

Interesting, here an example from a 8 cores machine running my vms:

[nsoffer at jumbo ~]$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5
  CPU6       CPU7
  0:         31          0          0          0          0          0
     0          0  IR-IO-APIC-edge      timer
  1:          2          0          0          1          0          0
     0          0  IR-IO-APIC-edge      i8042
  8:          0          0          0          0          0          0
     0          1  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0
     0          0  IR-IO-APIC-fasteoi   acpi
 12:          3          0          0          0          0          0
     1          0  IR-IO-APIC-edge      i8042
 16:          4          4          9          0          9          1
     1          3  IR-IO-APIC  16-fasteoi   ehci_hcd:usb3
 23:         13          1          5          0         12          1
     1          0  IR-IO-APIC  23-fasteoi   ehci_hcd:usb4
 24:          0          0          0          0          0          0
     0          0  DMAR_MSI-edge      dmar0
 25:          0          0          0          0          0          0
     0          0  DMAR_MSI-edge      dmar1
 26:       3670        354        215    9062370        491        124
   169         54  IR-PCI-MSI-edge      0000:00:1f.2
 27:          0          0          0          0          0          0
     0          0  IR-PCI-MSI-edge      xhci_hcd
 28:  166285414          0          3          0          4          0
     0          0  IR-PCI-MSI-edge      em1
 29:         18          0          0          0          4          3
     0          0  IR-PCI-MSI-edge      mei_me
 30:          1        151         17          0          3        169
    26         94  IR-PCI-MSI-edge      snd_hda_intel
NMI:       2508       2296       2317       2356        867        918
   912        903   Non-maskable interrupts
LOC:  302996116  312923350  312295375  312089303   86282447   94046427
90847792   91761277   Local timer interrupts
SPU:          0          0          0          0          0          0
     0          0   Spurious interrupts
PMI:       2508       2296       2317       2356        867        918
   912        903   Performance monitoring interrupts
IWI:          1          0          0          5          0          0
     0          0   IRQ work interrupts
RTR:          0          0          0          0          0          0
     0          0   APIC ICR read retries
RES:   34480637   12953645   13139863   14309885    8881861   10110753
 9709070    9703933   Rescheduling interrupts
CAL:    7387779    7682087    7283716    7135792    2771105    1785528
 1887493    1843734   Function call interrupts
TLB:      11121      16458      17923      15216       8534       8173
  8639       7837   TLB shootdowns
TRM:          0          0          0          0          0          0
     0          0   Thermal event interrupts
THR:          0          0          0          0          0          0
     0          0   Threshold APIC interrupts
MCE:          0          0          0          0          0          0
     0          0   Machine check exceptions
MCP:       7789       7789       7789       7789       7789       7789
  7789       7789   Machine check polls
HYP:          0          0          0          0          0          0
     0          0   Hypervisor callback interrupts
ERR:          0
MIS:          0

It seems that our default (CPU1) is fine.

Francesco, what do you think?

Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20151129/5c231569/attachment-0001.html>


More information about the Devel mailing list