On Sun, Nov 29, 2015 at 5:37 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Sun, Nov 29, 2015 at 10:37 AM, Yaniv Kaul <ykaul(a)redhat.com>
> On Fri, Nov 27, 2015 at 6:55 PM, Francesco Romani <fromani(a)redhat.com>
>> 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 &
> just use 0x3, as the man suggests) might be a tiny of a fraction faster
> execute taskset with, instead of the need to translate the numeric CPU
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
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
> 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
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
(my SATA controller)
43: 14664923 34 18 13 IR-PCI-MSI 327680-edge
(my dock station connector)
45: 6754579 4437 2501 2419 IR-PCI-MSI 32768-edge
47: 187409 11627 1235 1259 IR-PCI-MSI 2097152-edge
The user can modify this configuration on the host, I guess we need
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?