sleep

[bmeneguele@gmail.com (Bruno E. O. Meneguele)]

On 26-10, Tobin C. Harding wrote:
> Is there any 'non-process' context apart from interrupt context? I had a
> re-read of sleep sections in ldd3 and in Robert Love's book but am still
> not totally clear on this.
> 
> The reason for the question is understanding when we cannot sleep.

Well, AFAIK you can simplify things to interrupt vs process context, but
you might be aware that inside interrupt context there are others (NMI,
HWIRQ, SOFTIRQ, ..), infos that you can find in Robert's book. What
confused me for sometime was the 'atomic' vs 'interrupt' naming, but
after reading Robert's book it cames to the fact that they're the same.

The general rule is that in any interrupt context you can't sleep, and
why is that? Because interrupts aren't processes, there isn't an actual
process that the scheduler can put to sleep and wake it up later. It's
basically a design decision. Kernel-RT patches provide the feature of
sleepable interrupts, since the goal there is the latency and not
performance. That said, in short, the idea in Linux Kernel (I'm not an
expert, far from that actually, so anyone can correct me) is to make
interrupts atomic in behalf of simplicity and performance.

But hey, be careful, there are that talk about top vs bottom halves
mechanisms (to defer work) right? Top are always in interrupt context,
but bottom ones can run in process context. The most basic ones are
Softirqs, Tasklets and Workqueues, the former is the most low-level
available and I won't talk about it, but basicaly softirqs and tasklets
run in interrupt context, thus can't sleep, while workqueues is handled
in process context, thus can sleep normally (it can be rescheduled).

But as I said, I'm far from expert in the subject. What I've said here
is just what I know about :)

Hope it helps you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171114/d5bd8b2e/attachment-0001.bin