On Thu, Oct 26, 2017 at 9:56 AM Yaniv Kaul <ykaul@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel