From: abhitheextremeeng@gmail.com (Abhinav Misra)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Queries on bottom halves
Date: Sun, 2 Sep 2018 20:58:14 +0530 [thread overview]
Message-ID: <CAHJZ6qFJ=+UrMxLB6z4rOtvNjudgL4+ZH8xSmFoPiwqdYRvTbw@mail.gmail.com> (raw)
In-Reply-To: <ef8c9ad1-f97b-1bfc-2837-771db635efc8@suse.com>
Hi Larry,
Based on your answers below are my further queries.
1. *Does softirq and tasklet will always runs in ksoftirqd thread context ?*
As it is mentioned in the LKD (by robert love Pg-138) that there are
multiple places where pending softirq's
are checked. Out of that one is in return from hardware interrupt code path
i.e in do_irq function.
If that is the case then it will be running in the irq context with just
the interrupts enabled.
Now I know LKD is old and based on linux kernel 2.6. *Is that above
scenario is changed in new version of kernel ?*
Even I tried one example mentioned in LDD by Jerry cooperstein and printing
the pid of current task (current->pid) in the
tasklet which is getting scheduled by the shared interrupt from n/w card.
Every time it is printing the pid of the ksoftirqd thread.
So does that mean, now in latest kernel, softirq and tasklet will always
run in context of ksoftirqd thread ?
2. If we can sleep or use blocking calls in softirq's and tasklets then
*what is the difference between softirq/tasklet and workqueue's ?*Because
in old kernel, the main difference between softirq/tasklet and workqueue's
(Wq's) is that Wq's runs in process context
and hence sleep is allowed while the same is not the case with other
counterparts.
But if in new kernel this implementation is changed then why we need so
many options to defer the work as all of them are basically getting
executed in almost the same way.* In that case code running softirq,
tasklet, workqueue and kernel thread are all same ?*
If this is true then why we just remove all these these option and keep one
or two alternative.
There's one old link which also talks something about this.
*https://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-November/003812.html
<https://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-November/003812.html>*
BR,Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180902/b0f2f85c/attachment.html>
next prev parent reply other threads:[~2018-09-02 15:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-27 17:14 Queries on bottom halves Abhinav Misra
2018-08-27 18:31 ` Chinmay V S
2018-09-01 8:05 ` Abhinav Misra
2018-09-02 10:54 ` Larry Chen
2018-09-02 15:28 ` Abhinav Misra [this message]
2018-09-02 17:39 ` valdis.kletnieks at vt.edu
2018-09-02 17:44 ` Greg KH
2018-09-03 4:23 ` Larry Chen
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='CAHJZ6qFJ=+UrMxLB6z4rOtvNjudgL4+ZH8xSmFoPiwqdYRvTbw@mail.gmail.com' \
--to=abhitheextremeeng@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).