All of lore.kernel.org
 help / color / mirror / Atom feed
From: me@tobin.cc (Tobin C. Harding)
To: kernelnewbies@lists.kernelnewbies.org
Subject: sleep
Date: Wed, 15 Nov 2017 07:41:47 +1100	[thread overview]
Message-ID: <20171114204147.GA905@eros> (raw)
In-Reply-To: <20171114165206.GA3805@glitch>

On Tue, Nov 14, 2017 at 02:52:06PM -0200, Bruno E. O. Meneguele wrote:
> 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.

thanks for your response,
Tobin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171115/94d3e61b/attachment.bin 

  reply	other threads:[~2017-11-14 20:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-26  0:12 sleep Tobin C. Harding
2017-10-28 12:41 ` sleep Bogdan Lazic
2017-11-14 16:52 ` sleep Bruno E. O. Meneguele
2017-11-14 20:41   ` Tobin C. Harding [this message]
2017-11-14 20:53   ` sleep Max Filippov
2017-11-16 13:34     ` sleep Bruno E. O. Meneguele
  -- strict thread matches above, loose matches on Subject: below --
2002-10-03  1:48 Sleep linuxguruguy
2002-10-04  2:05 ` Sleep William Lee Irwin III
2002-10-04  2:26   ` Sleep Andrew Morton
2002-10-04  5:39     ` Sleep Gerrit Huizenga
2002-10-07 13:54   ` Sleep Bernd Petrovitsch
2002-10-04  3:15 ` Sleep Joe Kellner
2002-10-04  8:07 ` Sleep jbradford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171114204147.GA905@eros \
    --to=me@tobin.cc \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.