0

I was reading this link just now and it got me thinking.

A while back I was launching simulations on up to 30 cores of a 32core VM, and was doing so with a wrapper script that called nohup perl ...<rest of command>... and redirected the STOUT/STDERR - I'm not sure the specifics are that relevant, so I'll spare you the details.

I'm conceptually happy with multithreaded tasking, but I naively just assumed that backgrounding each process in my nohup call (each process was a separate simulation that then ran for several weeks), was sufficient to place each child process onto a core/thread of its own and then just chug onwards to completion, without appealing to GNU Parallels or something.

I checked in on them periodically, and always saw that 30 vCPUs were working on the tasks, everything completed in reasonable time so nothing seems amiss with my logic so far...

Somebody (I think on a SO page somewhere) told me that this might end up causing "CPU thrashing".

So my question has a couple of interrelated parts:

  • Firstly, was I wrong to assume nohup and/or backgrounding is sufficient to stick a process on a particular core? (And can the process that's running on a specific core be displayed in terminal? Top only tells you which cores are busy, not what task they're executing to my knowledge?)
  • Secondly, will CPU thrashing occur even if there are 2 spare CPUs available to handle the systems other tasks?
  • Lastly, if I wasn't wrong, does a given process get pinned to a specific CPU, and only that CPU, or will they jump around between threads depending on call order/timing etc. i.e. if I looped over files, will the first one get pinned to CPU 0, then 1, 2 and so on until completion?
2

nohup doesn't set anything up to keep a process on a particular core. You'd typically use taskset along with nohup to do that. top can show which core a process was last scheduled on, it's the P column.

Process and thread scheduling has grown quite complex over the years, because there are more and more factors to take into account: CPU affinity, cache affinity, interrupt handling, power envelopes... But I wouldn't expect any thrashing if you're starting fewer jobs than you have cores available, assuming the system isn't too busy from other tasks. In a similar fashion, you can't really predict what CPU a task will run on, but if it's appropriate, the scheduler is quite likely to keep it on the same core once it's picked a core.

3

Firstly, was I wrong to assume nohup and/or backgrounding is process that's running on a specific core be displayed in terminal? Top only tells you which cores are busy, not what task they're executing to my knowledge?)sufficient to stick a process on a particular core? (And can the

Nohup runs command exactly as if they were run without, only difference is they are removed from a list of pids to send a signal to on exit. (disown works for process not started with nohup).

Secondly, will CPU thrashing occur even if there are 2 spare CPUs available to handle the systems other tasks?

Only if CPU thrashing happens without nohup...

Lastly, if I wasn't wrong, does a given process get pinned to a specific CPU, and only that CPU, or will they jump around between threads depending on call order/timing etc. i.e. if I looped over files, will the first one get pinned to CPU 0, then 1, 2 and so on until completion?

same as without nohup...

you can view which cpu core a process is running on with ps, and you can limit or change limits on cores using taskset.

ps -eo pid,sgi_p,cmd --sort sgi_p

taskset -c -p 0 1234

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.