On Sun, Nov 29, 2015 at 5:37 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Nov 29, 2015 at 10:37 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
>
> On Fri, Nov 27, 2015 at 6:55 PM, Francesco Romani <fromani@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.


> 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)

Y.



The user can modify this configuration on the host, I guess we need to
expose this
on the engine side (cluster setting?).

Also if vdsm is pinned to certain cpu, should user get a warning
trying to pin a vm
to this cpu?

Michal, what do you think?

Nir