The meaning of Tasks and Running in htop screen

The “running” field in top doesn't show the number of tasks that are simultaneously running, it shows the number of tasks that are runnable, that is, the number of tasks that are contending for CPU access.

If top could obtain all system information in a single time slice, the “running” field would be exactly the number of tasks whose status (S column) show R (again, R here is often said to mean “running”, but this really means “runnable” as above). In practice, the number may not match because top obtains information for each task one by one and some of the runnable tasks may have fallen asleep or vice versa by the time it finishes. (Some implementations of top may just count tasks with the status R to compute the “running” field; then the number will be exact.)

Note that there is always a runnable task when top gather its information, namely top itself. If you see a single runnable task, it means no other process is contending for CPU time.

hi is the time spent processing hardware interrupts. Hardware interrupts are generated by hardware devices (network cards, keyboard controller, external timer, hardware sensors, ...) when they need to signal something to the CPU (data has arrived, for example).

Since these can happen very frequently, and since they essentially block the current CPU while they are running, kernel hardware interrupt handlers are written to be as fast and simple as possible.

If long or complex processing needs to be done, these tasks are deferred using a mechanism call softirqs. These are scheduled independently, can run on any CPU, can even run concurrently (none of that is true of hardware interrupt handlers).

_{The part about hard IRQs blocking the current CPU, and the part about softirqs being able to run anywhere are not exactly correct, there can be limitations, and some hard IRQs can interrupt others.}

As an example, a "data received" hardware interrupt from a network card could simply store the information "card ethX needs to be serviced" somewhere and schedule a softirq. The softirq would be the thing that triggers the actual packet routing.

si represents the time spent in these softirqs.

A good read about the softirq mechanism (with a bit of history too) is Matthew Wilcox's I'll Do It Later: Softirqs, Tasklets, Bottom Halves, Task Queues, Work Queues and Timers (PDF, 64k).

st, "steal time", is only relevant in virtualized environments. It represents time when the real CPU was not available to the current virtual machine — it was "stolen" from that VM by the hypervisor (either to run another VM, or for its own needs).

The CPU time accounting document from IBM has more information about steal time, and CPU accounting in virtualized environments. (It's aimed at zSeries type hardware, but the general idea is the same for most platforms.)