1

I'm running iperf in server mode on a Ubuntu box (14.04 LTS). The hardware is quad core with hyper-threading, so I have cores 0-7 available (0 is paired with 4, 1 with 5 and so on).

I've set the processor affinity of the running iperf process to use only processors 0,1. I can verify this with taskset:

$ taskset -pc 27745
pid 27745's current affinity list: 0,1

If I view the process in top or htop then the process correctly shows as only ever running on one of those cores. However, if I switch to thread view then I see the child threads running on arbitrary cores.

Is top/htop misleading me somehow? Can this genuinely happen? If so, why and how do I prevent it?

EDIT

I should comment that whilst I see this with iperf I'm not necessarily implying it's iperf specific. It just happens to be the setup I have. If I can't get to the bottom of this then I'll likely play around with other executables and see if the behaviour is reproducible.

Gilles 'SO- stop being evil'
  • 829,060
Andrew Parker
  • 133
  • 7
  • 1
    It could be that some child threads were running before you set the affinity. How did you set the affinity? – ctrl-alt-delor Jul 18 '16 at 09:57
  • I'm 99.9% sure that's not possible. I'm using Ansible scripts to terminate the process, restart it and then run taskset to set the affinity. I'll sanity check tomorrow but everything I've seen leads me to believe the scripts are behaving as expected. – Andrew Parker Jul 18 '16 at 13:50

1 Answers1

1

I got to the bottom of this (sort of). It was down to the unusual way I was launching iperf from ansible. Originally I hadn't spotted that iperf had a daemon mode (-D) so I was manually starting iperf with daemon. I'd forgotten about this and not got around to changing it.

Strangely, if I start iperf using this method then it seems to immediately spawn some extra threads. Note that I don't mean the child processes that daemon has to start in order to properly detach the child process properly (i.e. make sure it's not a process group leader, it a child of init etc.). The iperf process itself once started is starting some extra threads it seems (unless this really is a facet of running daemon - but they genuinely appear to be threads according to htop).

I was taskset-ting both the daemon process and the iperf process for good measure but I guess this missed the child threads (see here for a discussion around this: Setting running process affinity with taskset fails). I'm not convinced this is the full story as I don't see the main iperf process running on the correct processor so something fishy is going on. I'm sure it can be explained by better investigation of the behaviour of daemon but I don't have time to investigate that right now so I'll leave it at that.

Community
  • 1
Andrew Parker
  • 133
  • 7