2

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
  • 1
    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." Commented Sep 5, 2020 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" Commented Sep 5, 2020 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! ;-) ) Commented Sep 5, 2020 at 19:58
  • @MC68020 very interesting point! Commented Sep 5, 2020 at 20:04

2 Answers 2

0

The following command did the trick:

ps -mo pid,tid,%cpu,psr -p <main process ID>

Options explained:

  • -m - show threads after processes
  • -o - user-defined format, showing process ID, "the unique number representing a dispatchable entity" (thread ID), CPU utilization, and the processor the process is currently assigned to
  • -p for the given process ID

The above pertain to Linux ps only and will not work on macOS/BSD.

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. Commented Sep 5, 2020 at 23:17
  • Apologizes : To read "all CPUs involved are mainly idle" instead of "all tasks involved are mainly iddle" in the above comment. Commented Sep 5, 2020 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. Commented Sep 5, 2020 at 23:32
  • 1
    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. Commented Sep 6, 2020 at 8:11
0

using top if you hit h to get the help menu, it will explain...

  • F for fields
  • the ones with * are what are marked as to be displayed
  • look for P which is Last Used CPU (SMP)
    • use the down arrow key on keyboard to move the highlight down to P then hit spacebar to put a * to it
  • hit escape to go back to the running top display, notice the new P column that will correspond to cpu core number
  • H to toggle threads on/off
  • s to update display delay, I like 1 sec versus the default 3, do 0.1 if you prefer
  • i to toggle idle processes on/off; u to filter on user; o to customize filter
  • W to save this top configuration so the P column shows from now on when you run top.
8
  • Could you please explain how (apart from precise cpu isolation) launching top would not immediately trigger some change in the distribution and therefore offer some picture more or less radically different to the situation where top was not running ? Commented Feb 1, 2024 at 19:57
  • no, i cannot explain, other than what is described from the top help menu. top will display processes jumping to different P core numbers, thats all i know in regards to that Commented Feb 1, 2024 at 20:29
  • Of course you cannot. Nobody could. My point here is the same I tried to express in comments of OP' question & answer : Exactly the same with benchmarks. (But top is even worse to that respect) Whatever you launch will actually modify the picture you wanted. Anyway… since OP apparently does not care… let it be. However, I'd be personally happy to upvote your answer provided you include some suggestion to pin top on some core excluded from the list of cores made available to the application to watch. Then, the more core you get, the less pollution you'll get. Commented Feb 1, 2024 at 20:47
  • As a proof regarding (h)top polluting the desired result (which core being used by some thread) just launch the multithreaded cpu-bound application and observe the rate of rescheduling interrupts, then launch (h)top… and observe the rate of these interrupts… what can you deduce ? Commented Feb 1, 2024 at 22:10
  • processes will jump all other the place on cores as normal behavior unless some kind of cpu affinity is applied. I observe this all the time running commercial software and top shows just fine some N number of processes/threads of that all having a consistent cpu (core) number under top's P column since it was started. As for getting which core a thread is running on one could use top with --batch and -n 1 however often via cron and then parse that output for what P core number whatever pid was running on when and see how it jumps around. Commented Feb 2, 2024 at 22:23

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.