4

I am a little confused about the status of a process I have. It looks like this:

$ ps -eal | head -n 1 ; ps -eal | grep perf
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S     0  7843  7842  0  80   0 - 10838 -      pts/6    00:00:00 perf

-- so, the status is S, which the man page describes as "S interruptible sleep (waiting for an event to complete)", it is waiting for some event. I assume it is listed in some waiting channel. But the waiting channel is: WCHAN -. Which man page describes with "Running tasks will display a dash ('-') in this column."

Plus, /proc/7843/status indeed contains State: S (sleeping) and /proc/7843/wchan contains 0. I guess 0 in proc//wchan tells the same thing -- that the task does not wait for anything.

Do I misunderstand something or do they contradict one another?

And the task indeed does not run -- I don't think - in wchan means it is waiting to be scheduled..

Could the wchan output be somehow misconfigured? I run Ubuntu 14.04, kernel 3.13.0-86-generic.

Checking other process shows:

$ ps -eal | head -n 1 ; ps -eal | grep fish
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000  2407  2399  0  80   0 - 47675 wait   pts/0    00:00:07 fish
1 S  1000  2409     1  0  80   0 -  5500 poll_s ?        00:00:00 fishd
0 S  1000  2507  2399  0  80   0 - 45333 poll_s pts/3    00:00:00 fish
0 S  1000  2567     1  0  80   0 -  8366 wait   ?        00:00:00 fish

-- so here WCHAN is ok.

1

2 Answers 2

2

Note that the process state and wchan isn't returned atomically by the kernel.

That means between accessing the process' state and getting its wchan information its state may very well change from sleeping to running.

Thus, there is a race.

The stack walking procedure inside the kernel for obtaining the wchan information is racy, as well and might not cover all cases.

You can cross-check with cat /proc/$pid/stack (root-only) or cat /proc/$pid/syscall to get some additional information on where the process is stuck in the kernel.

1
  • if I remember correctly, that perf command looked like stuck. But probably it did wake up very quickly to process some performance events and go back to sleep. Then indeed the state was changing too quickly and the kernel diagnostics did not keep up.
    – xealits
    Nov 8, 2020 at 16:57
1

The WCHAN value seems to be computed. From kernel sources arch/x86/Kconfig:

config SCHED_OMIT_FRAME_POINTER 
   Single-depth WCHAN output
   Calculate simpler /proc/<PID>/wchan values. If this option
   is disabled then wchan values will recurse back to the
   caller function. This provides more accurate wchan values,
   at the expense of slightly more scheduling overhead.

and from Documentation/filesystem/proc.txt:

wchan Present with CONFIG_KALLSYMS=y: it shows the kernel function
      symbol the task is blocked in - or "0" if not blocked.

so I guess sometimes there is a miscomputation of wchan.

1
  • However, OP demonstrated that in his case he get proper symbolic wchan information for some processes. With a kernel mis-configuration it should never work, shouldn't it? Nov 7, 2020 at 12:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .