Queries on bottom halves

Queries on bottom halves

[Abhinav Misra]

Hi,

I have few queries regarding bottom halves-

1. Interrupts use their own per cpu stack for their execution.Which stack
does the bottom halves use for their execution ?

2. Why can't we sleep in bottom halves ?

BR,Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180827/20df5c96/attachment.html>

Queries on bottom halves

[Chinmay V S]

> 1. Which stack does the bottom halves use for their execution ?
Modern "bottom-half" implementations built on top of kernel threads
use the stack of the underlying thread.
(just like how any thread on the system does)

> 2. Why can't we sleep in bottom halves ?
We can!
Modern bottom half implementations can sleep i.e. relinquish CPU to
other threads.


Q. What are Bottom Halves?

Ans. A piece of code that is...

a. scheduled/executed asynchronously from the triggering event (interrupt).
(compared to the "top-half" i.e. the ISR that is executed synchronously)

b. and usually can take significant amount of time.
(compared to the time taken by the "top-half" i.e. ISR)

Over the years, several implementations of the "Bottom Halves" concept
have been developed on the Linux kernel. Co-incidentally, one of the
oldest (now deprecated) implementation was itself called Bottom-Halves.

There are several modern implementations of bottom-halves :
Soft-IRQs, Tasklets, and Workqueues. The latter/recent approaches to
implementing bottom-halves are wrappers around Linux kernel threads.

I have tried to summarize these various "Bottom Half" implementations
within the Linux kernel and provide some commentary of their
development over the years in the following slide deck:
https://thecodeartist.blogspot.com/2018/06/bottom-halves-on-linux.html

For more details,
checkout the various links to wikis and articles in
the last slide "References / Recommended Reading" in the above slide-deck.

regards
CVS

Queries on bottom halves

[Abhinav Misra]

Hi,

Sorry for the delay in the reply.
I think the question is not correctly framed. Will try to do it again.

1. Which stack does the tasklet, softriq and workqueue use for their
execution ?

2. Why can't we sleep in tasklet and softriq ?

BR,Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180901/62cdc3c0/attachment.html>

Queries on bottom halves

[Larry Chen]

Hello Abhinav,

On 09/01/2018 04:05 PM, Abhinav Misra wrote:
> Hi,
> 
> Sorry for the delay in the reply.
> I think the question is not correctly framed. Will try to do it again.
> 
> 1. Which stack does the tasklet, softriq and workqueue use for their 
> execution ?
> 

Softirq actually is a group of N kernel threads(N equals to your cpu 
number), each thread is restricted to run on its corresponding cpu.

A tasklet is a call-back function that runs on softirq thread.

In the latest kernel version, a tasklet uses softirq thread stack.

A workqueue is almost the same, a work is almost the same as the a 
tasklet, it runs on a worker thread and shares the stack with worker thread.


> 2. Why can't we sleep in tasklet and softriq ?
Yes, you can.
Tasklet runs on softirq thread, it has its own task_struct, you can 
sleep or call schedule in your tasklet.

When you sleep in your tasklet, the softirq thread that the tasklet is 
running on will sleep, the sequential tasklet could not be executed 
until next schedule.

BR,
Larry

Queries on bottom halves

[Abhinav Misra]

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>

Queries on bottom halves

[valdis.kletnieks at vt.edu]

On Sun, 02 Sep 2018 20:58:14 +0530, Abhinav Misra said:

> 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.

-ENOPATCH

Often the gain from simplification isn't enough to motivate somebody to
actually do all the work of coding and exhaustively testing the patch series.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180902/f3366a30/attachment.sig>

Queries on bottom halves

[Greg KH]

On Sun, Sep 02, 2018 at 01:39:07PM -0400, valdis.kletnieks at vt.edu wrote:
> On Sun, 02 Sep 2018 20:58:14 +0530, Abhinav Misra said:
> 
> > 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.
> 
> -ENOPATCH
> 
> Often the gain from simplification isn't enough to motivate somebody to
> actually do all the work of coding and exhaustively testing the patch series.

Also, when switching to a different mechanism (or combining them), odd
things happen due to the fact that those different methods do work just
a little bit differently.

This was recently shown by some noticable slowdowns in some USB device
paths like cameras, when one low-level primative in one subsystem moved
from one type to another to try to "simplify" things.

So Valdis is right, the only way this could ever be done is if someone
does the work.  And it's a lot of non-trivial work to do...

greg k-h

Queries on bottom halves

[Larry Chen]

Hi Abhinav,

On 09/02/2018 11:28 PM, Abhinav Misra wrote:
> 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 
                            ~~ --->> Sorry, does "it" mean softirq or 
somethine else??
do_irq just wake up softirq thread. That does not mean softirq runs in 
irq context.

> 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 ?

Yes.

> 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 ?

That's another question, workqueue and tasklet is two machnisms provided 
for async operations. Generally I think workqueue is more powerful and 
flexible. You can get more info from kernel docs.


> *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.
I refered to kernel 2.6 version, softirq and tasklet are still almost 
the same machnism with the latest version.

Here is an explanation

https://www.safaribooksonline.com/library/view/understanding-the-linux/0596005652/ch04s07.html

> 
> 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.
> 
Emmm... tasklet and workqueue have something in common, but I think 
tasklet can satisfy simple scenarios, while workqueue, I think is more 
powerfull and flexible, does well in more complicated scenarios.

Maybe when you make clear what's their difference, you'll understand more.

BR,
Larry