CPU affinity / taskset does not always work.

lwi · 02-20-2010, 04:33 PM

I have a program for which it seems to be impossible to set cpu affinity from launch with the command taskset -c <cpu list> <command> <arguments>

It seems to work fine with xclock:

Code:

vision@ackbar:~$ taskset -c 0,1 xclock -digital &
[1] 15997
vision@ackbar:~$ taskset -pc $!
pid 15997's current affinity list: 0,1

but when I try it with my own program, it launches correctly but the cpu affinity is not set like I want it to.

I can however set it afterwards using it's PID:

Code:

vision@ackbar:~$ taskset -c 0,1 ltplayerlua < /dev/null >&/dev/null &
[2] 16170
vision@ackbar:~$ taskset -pc $!
pid 16170's current affinity list: 0
vision@ackbar:~$ taskset -pc 0,1 16170
pid 16170's current affinity list: 0
pid 16170's new affinity list: 0,1
vision@ackbar:~$ taskset -pc 16170
pid 16170's current affinity list: 0,1

.. it works but I find it very annoying that I can't set it right from the start.

any ideas?

thanks in advance,

Lwi

rigor · 02-28-2010, 09:54 PM

Is ltplayerlua a binary or a script?

Are you attempting to redirect file descriptors for taskset, or for ltplayerlua?

lwi · 03-01-2010, 11:21 AM

it's a binary, and the redirections are meant for ltplayerlua... I'm kinda seeing where you are going with this, but the redirections seem to be working fine, i.e. no output on the terminal.

How would the redirections make taskset not work?

rigor · 03-01-2010, 12:49 PM

I'm not sure how the redirection works in your environment. But, AFAIK, in some
environments, the shell would be doing the redirection for the taskset command
initially, not the ltplayerlua, because you haven't escaped the redirections.

As far as the shell syntax is concerned, taskset is the command. It doesn't know
that ltplayerlua is a command. To the shell, ltplayerlua is just an argument to
the taskset command.

Then, if your environment was set up not to close file descriptors during execution
of a subtask, ltplayerlua could inherit that redirection once it executes. With
some programs, if they are not connected to a tty, they conclude that they are
running in the background, and behave differently. In your environment, if the
redirections do first apply to taskset, since it's then no longer associated with
a tty, maybe it behaves differently.

In my environment, I know of no documentation that says that taskset will behave
differently if it's running in the background. So I know of no specific reason why
it would. But you're doing two things that are similar, you're expecting similar
results, and you're not getting similar results. I often find that looking at the
differences between two similar things, one that works and one that doesn't, allows
me to get the one that wasn't working, to work, without having to explain exactly
why it didn't work in the first place.

You might want to try to find a way to force the redirections to apply only to
ltplayerlua. Or for now, just hard code the use of /dev/null internal to
ltplayerlua just to see if it works that way.