Re: Queries on bottom halves

2018-09-02 Thread 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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Queries on bottom halves

2018-09-02 Thread Greg KH
On Sun, Sep 02, 2018 at 01:39:07PM -0400, valdis.kletni...@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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Queries on bottom halves

2018-09-02 Thread valdis . kletnieks
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.



pgp0Q_VO4bNNu.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Queries on bottom halves

2018-09-02 Thread 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
*

BR,Abhinav
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Queries on bottom halves

2018-09-02 Thread 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


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies