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?