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?
does nohup place each process on one core specifically
cpu;nohup;parallelism
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.