Does uninterruptible tasks consume CPU time?

Question

Assumption

My assumption is what I myself consider fact based on my understanding:

1. Tasks in either TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE state are not "runnable". As such, they are not considered by the scheduler when it picks the next task to run (ref Linux Kernel Development chap 4].
2. TASK_UNINTERRUPTIBLE only differs from TASK_INTERRUPTIBLE in that a signal such as SIGTERM does not affect the former.
3. This means that TASK_UNINTERRUPTIBLE/TASK_INTERRUPTIBLE should not consume CPU time at all.

What I've seen people talking

1. https://stackoverflow.com/questions/223644/what-is-an-uninterruptible-process
2. https://superuser.com/questions/791840/how-can-a-process-in-interruptible-sleep-state-use-100-cpu

Many comments/answers in two links above said that:

1. TASK_UNINTERRUPTIBLE can't be affected by SIGNAL (such as SIGTERM).
2. The task must run to finish and shouldn't be interrupted, as in the case with a "quick" disk I/O (as opposed to "slow" I/O with things like tty).

Only one answer (the second link) explicitly said that UNINTERRUPTIBLE tasks consume CPU in that "the CPU is stuck" because the task can't be affected by a SIGNAL.

Question

1. Does an uninterruptible task consume CPU?
2. If it does, then it's contradictory with my assumption. Which of my assumption is wrong?

Answer 1

Tasks in either interruptible or uninterruptible sleep are, first and foremost, asleep, so as you say they aren’t runnable, don’t get scheduled and therefore don’t consume CPU.

The confusion in the SU question probably stems from the fact that CPU usage measurement (in top and elsewhere) is interval-based, whereas a process state is measured at a specific point in time. It is thus technically possible for a process to be scheduled over 100% of its last measurement interval, and thus appear as consuming 100% of a CPU in top (or more, if it has multiple scheduled threads), and yet be in a non-runnable state when top checks its state.