On Thu, Oct 26, 2017 at 9:56 AM Yaniv Kaul <ykaul(a)redhat.com> wrote:
I'm looking at some supervdsm log, and I'm seeing these
commands:
/usr/bin/taskset --cpu-list 0-55 /usr/libexec/vdsm/fc-scan
and:
/usr/bin/taskset --cpu-list 0-55 /usr/bin/mount -t nfs -o
soft,nosharecache,timeo=600,retrans=6 10.10.10.1:/NFS/images
And so on (also for iscsiadm).
Why do we need to taskset commands if we allow them to run on all CPUs?
Why would we allow them to run on all CPUs anyway?
Vdsm is running by default only on the second cpu. When we run external
commands we
unpin the command by default so it can run on any cpu. supervdsm inherit
the default
behavior by using vdsm.command.execCmd().
Since we do not pin supervdsm to any cpu, we can avoid the useless taskset
wrapper by using execCmd(reset_cpu_affinity=False) from supervdsm. But since
supervdsm code is mixed with vdsm code, it is hard to tell if a piece of
code is running in supervdsm or in vdsm and error prone.
If we have proper separation between code running in vdsm (vdsm user) and
code running in supervdsm (as root) this would be easy and much more
secure.
Nir
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel