Can a Bottom half be scheduled from a kernel thread
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread. what are the pros and crons of doing so? thanks, Vishwas S
Hi Vishwas,
From what I have read, tasklet run in interrupt context and work queues run via kernel thread in process context. So, you cannot schedule a tasklet on a kernel thread. Thanks, Arun
On May 12, 2014 5:06 PM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread. what are the pros and crons of doing so? thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a
tasklet can be scheduled from a kernel thread. You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Appreciate the quick response.. Hi All, i am concerned about the scheduling the tasklet. The running of the tasklet is anyway controlled by the kernel at its own dissertation. But scheduling can be done from anywhere?? Correct? Also can Tasklets can be used for "any" deferred work or it is strictly stick to the work which can not be done in the "top" half?? For example, if there is some work which is prepared ready by a kernel thread (but thread dont want to process it immediately, rather want to deffer it for sometime) and the intention is to process this "prapared work" at some later time. In the situation like this, can we use the tasklet to do this? On Tue, May 13, 2014 at 6:28 AM, Pranay Srivastava <pranjas@gmail.com>wrote:
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a
tasklet can be scheduled from a kernel thread.
You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
For example, if there is some work which is prepared ready by a kernel thread (but thread dont want to process it immediately, rather want to deffer it for sometime) and the intention is to process this "prapared work" at some later time. In the situation like this, can we use the tasklet to do this?
Isn't the purpose of the (kernel) thread itself is to DO deferred work? Tasklets, if I remember, are run only once at *some* later stage of processing an interrupt. Why can't use another kernel thread itself (or maybe even a timer) to schedule your work? See this link which explains the difference between the 2 succinctly: http://www.makelinux.net/ldd3/chp-7-sect-6 HTH, -mandeep
On Tue, May 13, 2014 at 6:28 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread.
You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, May 13, 2014 at 2:18 PM, Vishwas Srivastava <vishu.kernel@gmail.com> wrote:
Appreciate the quick response..
Hi All, i am concerned about the scheduling the tasklet. The running of the tasklet is anyway controlled by the kernel at its own dissertation. But scheduling can be done from anywhere?? Correct?
I think by the next tick it would run. Since when you do tasklet_schedule you are setting the softirq pending flag.
Also can Tasklets can be used for "any" deferred work or it is strictly stick to the work which can not be done in the "top" half??
Really depends, what I think is that you still wouldn't want to do too much in tasklet, if it's heavy processing better give it a work-queue. So basically use tasklet as a breakup of your top half only. That timely things still are done quick indeed just not that quick.
For example, if there is some work which is prepared ready by a kernel thread (but thread dont want to process it immediately, rather want to deffer it for sometime) and the intention is to process this "prapared work" at some later time. In the situation like this, can we use the tasklet to do this? queue_delayed_work? or maybe you can do just a kthread_create only for the thread and wakeup_process(<your_kthread>) when you want to run it.
You can do anything inside the code that's upto you, only rule is no sleepy things, and no copy_to_ or copy_from both can sleep and both require process context which you don't have. Besides the no sleeping rule, you can do whatever you like. By scheduling, I mean scheduling the current code by explicitly calling schedule or some other sleeping function call. But you can wake_up, tasklet_schedule, complete, complete_all etc. you can do kmalloc, don't forget GFP_ATOMIC, but no vmalloc. You can do memcpy, but no copy_to/copy_from
On Tue, May 13, 2014 at 6:28 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread.
You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ---P.K.S
Yes, that sounds cool. But if you see, for Linux versions >= 3.4.1 some of the network drivers do not use the softirq or NAPI interface, but instead use a kernel thread to process the received packets. In the situation like this, whatever packets are processed by the kernel thread, i just want to enqueue them in a software Q and want to deque them and transmit them at some later point of time. Is it okay to use tasklet for this purpose ? So essentially what i would be doing is something like this ... 1: Kernel thread will process the packets and will give me "skb" 2: i will enqueue this skb in SW Q and schedule a tasklet. 3: when kernel will decicde to run the tasklet, in the handler function of the tasklet, i will dequeue packets and will transmit it to another interface. Since in this implementation, i will schedule a tasklet from a kernel thread, i am a bit concerned if this approach is all right and am not sure if scheduling a tasklet from a kernel thread has any side effects. Probably now my problem is more clearer. Appreciate the response and suggestions of the experts. On Tue, May 13, 2014 at 3:28 PM, Pranay Srivastava <pranjas@gmail.com>wrote:
On Tue, May 13, 2014 at 2:18 PM, Vishwas Srivastava <vishu.kernel@gmail.com> wrote:
Appreciate the quick response..
Hi All, i am concerned about the scheduling the tasklet. The running of the tasklet is anyway controlled by the kernel at its own dissertation. But scheduling can be done from anywhere?? Correct?
I think by the next tick it would run. Since when you do tasklet_schedule you are setting the softirq pending flag.
Also can Tasklets can be used for "any" deferred work or it is strictly stick to the work which can not be done in the "top" half??
Really depends, what I think is that you still wouldn't want to do too much in tasklet, if it's heavy processing better give it a work-queue. So basically use tasklet as a breakup of your top half only. That timely things still are done quick indeed just not that quick.
For example, if there is some work which is prepared ready by a kernel thread (but thread dont want to process it immediately, rather want to deffer it for sometime) and the intention is to process this "prapared work" at some later time. In the situation like this, can we use the tasklet to do this? queue_delayed_work? or maybe you can do just a kthread_create only for the thread and wakeup_process(<your_kthread>) when you want to run it.
You can do anything inside the code that's upto you, only rule is no sleepy things, and no copy_to_ or copy_from both can sleep and both require process context which you don't have. Besides the no sleeping rule, you can do whatever you like. By scheduling, I mean scheduling the current code by explicitly calling schedule or some other sleeping function call. But you can wake_up, tasklet_schedule, complete, complete_all etc.
you can do kmalloc, don't forget GFP_ATOMIC, but no vmalloc. You can do memcpy, but no copy_to/copy_from
On Tue, May 13, 2014 at 6:28 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread.
You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ---P.K.S
On Wed, May 14, 2014 at 12:38 AM, Vishwas Srivastava <vishu.kernel@gmail.com> wrote:
Yes, that sounds cool. But if you see, for Linux versions >= 3.4.1 some of the network drivers do not use the softirq or NAPI interface, but instead use a kernel thread to process the received packets.
I think you got confused with processing and "getting" the packet. To get the packet most probably there would be an interrupt handler. Sure that handler could kickstart NAPI polling or not it's upto driver however in order to get the packet you'll need to have an interrupt handler, unless it's a loopback sort of device where you generate and route the packets on the same system.
In the situation like this, whatever packets are processed by the kernel thread, i just want to enqueue them in a software Q and want to deque them and transmit them at some later point of time. Is it okay to use tasklet for this purpose ?
Sure use whatever you like, but again as you mentioned you'll need to have that skb to give to thread. This getting the skb part would require you to code either interrupt handler or you can make that skb_orphan and wake up some thread that would do your receiving part so in this receiving done by thread case it's actually not going on wire.
So essentially what i would be doing is something like this ... 1: Kernel thread will process the packets and will give me "skb" 2: i will enqueue this skb in SW Q and schedule a tasklet. 3: when kernel will decicde to run the tasklet, in the handler function of the tasklet, i will dequeue packets and will transmit it to another interface.
Sounds complex, but i guess you are trying to learn to use tasklet so no harm. What I would suggest instead is in your ndo->xmit callback , schedule a tasklet which you know clear some imaginary flags of the device and then wake up a thread to do any processing. Going the other way as you mentioned, i guess in case you eventually want to do some allocation work then in tasklet you'll be limited.
Since in this implementation, i will schedule a tasklet from a kernel thread, i am a bit concerned if this approach is all right and am not sure if scheduling a tasklet from a kernel thread has any side effects.
No side affects as i mentioned, tasklet_schedule, tasklet_hi_schedule don't sleep. Just see that code pretty simple. But make sure to have spin_lock* protecting your lists with the thread and tasklet.
Probably now my problem is more clearer. Appreciate the response and suggestions of the experts.
On Tue, May 13, 2014 at 3:28 PM, Pranay Srivastava <pranjas@gmail.com> wrote:
On Tue, May 13, 2014 at 2:18 PM, Vishwas Srivastava <vishu.kernel@gmail.com> wrote:
Appreciate the quick response..
Hi All, i am concerned about the scheduling the tasklet. The running of the tasklet is anyway controlled by the kernel at its own dissertation. But scheduling can be done from anywhere?? Correct?
I think by the next tick it would run. Since when you do tasklet_schedule you are setting the softirq pending flag.
Also can Tasklets can be used for "any" deferred work or it is strictly stick to the work which can not be done in the "top" half??
Really depends, what I think is that you still wouldn't want to do too much in tasklet, if it's heavy processing better give it a work-queue. So basically use tasklet as a breakup of your top half only. That timely things still are done quick indeed just not that quick.
For example, if there is some work which is prepared ready by a kernel thread (but thread dont want to process it immediately, rather want to deffer it for sometime) and the intention is to process this "prapared work" at some later time. In the situation like this, can we use the tasklet to do this? queue_delayed_work? or maybe you can do just a kthread_create only for the thread and wakeup_process(<your_kthread>) when you want to run it.
You can do anything inside the code that's upto you, only rule is no sleepy things, and no copy_to_ or copy_from both can sleep and both require process context which you don't have. Besides the no sleeping rule, you can do whatever you like. By scheduling, I mean scheduling the current code by explicitly calling schedule or some other sleeping function call. But you can wake_up, tasklet_schedule, complete, complete_all etc.
you can do kmalloc, don't forget GFP_ATOMIC, but no vmalloc. You can do memcpy, but no copy_to/copy_from
On Tue, May 13, 2014 at 6:28 AM, Pranay Srivastava <pranjas@gmail.com> wrote:
On May 13, 2014 2:36 AM, "Vishwas Srivastava" <vishu.kernel@gmail.com> wrote:
Hi All, This may sound a dumb question. I just want to know if a tasklet can be scheduled from a kernel thread.
You can do tasklet_schedule in case I am getting your question.
what are the pros and crons of doing so?
Don't sleep or schedule the tasklet code. It needs to be atomic since it runs via TASKLET_SOFTIRQ.
thanks, Vishwas S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ---P.K.S
-- ---P.K.S
participants (4)
-
Arun S. Kumar -
Mandeep Sandhu -
Pranay Srivastava -
Vishwas Srivastava