-1

Let's say we have a CPU-intensive application called multi-threaded-application.out that is running on top of Ubuntu with a PID of 10000. It has 4 threads with tid 10001, 10002, 10003, and 10004. I want to know, at any given time, on which core each of these threads is being scheduled?

I tried /proc/<pid>/tasks/<tid>/status, but I couldn't find any information regarding the core ID that is responsible for running the given thread.

This question is somehow related to this one.

Any help would be much appreciated.

4
  • Related to stackoverflow.com/questions/8032372/… perhaps ? "To get the information you want, look in /proc/<pid>/task/<tid>/status. The third field will be an 'R' if the thread is running. The sixth from the last field will be the core the thread is currently running on, or the core it last ran on (or was migrated to) if it's not currently running." – steve Sep 5 '20 at 18:02
  • @steve The output of proc status is different than what's mentioned in that question. DavidSchwartz himself mentioned in the heading that "The answer below is no longer accurate as of 2014" – Michel Gokan Khan Sep 5 '20 at 19:19
  • I am afraid that unless its CPU0 and have designed strict CPU isolation (which if it was proven interesting is almost impossible to achieve... (on a working system I mean...)) the command you would issue might well change scheduler's mind at once! (Look at your count of rescheduling interrupts! ;-) ) – MC68020 Sep 5 '20 at 19:58
  • @MC68020 very interesting point! – Michel Gokan Khan Sep 5 '20 at 20:04
-1

The following command did the trick:

ps -mo pid,tid,%cpu,psr -p <main process ID>
4
  • I'll assume the responsibility of downvoting this answer. The OP writes about some 4-threaded "CPU-intensive application". If I assume that the 4 threads are more or less equally sharing the responsibility of the load then it is very unlikely that issuing the above command several times consecutively will provide identical results. On a standard non cpu isolated env, the only reason for successive occurrences of this command to produce identical results would be that all tasks involved are mainly idle. – MC68020 Sep 5 '20 at 23:17
  • Apologizes : To read "all CPUs involved are mainly idle" instead of "all tasks involved are mainly iddle" in the above comment. – MC68020 Sep 5 '20 at 23:24
  • As stated in some comment I made as part of OP's question, do consider the number of rescheduling interrupts. It simply tells the number of times the scheduler has believed pertinent to switch some thread from one CPU to another one. – MC68020 Sep 5 '20 at 23:32
  • Of course, it's not providing an identical result, because a thread migrates several times during its lifetime. What's wrong with it? I've tested and the output exactly matches the number of CPU migrations reported by perf. – Michel Gokan Khan Sep 6 '20 at 8:11

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.