Hi, I had asked a similar question before, but I've some doubts regarding the correctness of the following code. Please see the following code snippet from the file linux-2.6.37/arch/x86/kernel/apm_32.c. This is the core function of apm thread. Question: Suppose the apm thread has just completed execution of the line 1442 and the scheduling happens for some reason, AFAIK, since the apm thread's state has been set to TASK_INTERRUPTIBLE, it will be removed from the run-queue. So there is a chance for the apm thread to remain suspended indefinitely as nobody is there to wakeup the apm thread, correct? I'm asking this because the same function has been given as an example in the following link and would like to confirm the accuracy of the example. http://www.linuxjournal.com/node/8144/print 1437 static void apm_mainloop(void) 1438 { 1439 DECLARE_WAITQUEUE(wait, current); 1440 1441 add_wait_queue(&apm_waitqueue, &wait); 1442 set_current_state(TASK_INTERRUPTIBLE); 1443 for (;;) { 1444 schedule_timeout(APM_CHECK_TIMEOUT); 1445 if (kthread_should_stop()) 1446 break; 1447 /* 1448 * Ok, check all events, check for idle (and mark us sleeping 1449 * so as not to count towards the load average).. 1450 */ 1451 set_current_state(TASK_INTERRUPTIBLE); 1452 apm_event_handler(); 1453 } 1454 remove_wait_queue(&apm_waitqueue, &wait); 1455 } -- Thanks, Sudheer Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Hi Sudheer, If you see there is a schedule_timeout function called with some timeout so if you receive any signal ( handled by apm_event_handler ) before the timeout value it will be woken up and if it receives no signal before timeout value than scheduler will move this to RUNNABLE state again. Regards, Piyush On Thu, Mar 3, 2011 at 5:20 PM, <sudheer.divakaran@wipro.com> wrote:
Hi,
I had asked a similar question before, but I've some doubts regarding the correctness of the following code. Please see the following code snippet from the file linux-2.6.37/arch/x86/kernel/apm_32.c. This is the core function of apm thread.
Question: Suppose the apm thread has just completed execution of the line 1442 and the scheduling happens for some reason, AFAIK, since the apm thread's state has been set to TASK_INTERRUPTIBLE, it will be removed from the run-queue. So there is a chance for the apm thread to remain suspended indefinitely as nobody is there to wakeup the apm thread, correct?
I'm asking this because the same function has been given as an example in the following link and would like to confirm the accuracy of the example.
http://www.linuxjournal.com/node/8144/print
1437 static void apm_mainloop(void) 1438 { 1439 DECLARE_WAITQUEUE(wait, current); 1440 1441 add_wait_queue(&apm_waitqueue, &wait); 1442 set_current_state(TASK_INTERRUPTIBLE); 1443 for (;;) { 1444 schedule_timeout(APM_CHECK_TIMEOUT); 1445 if (kthread_should_stop()) 1446 break; 1447 /* 1448 * Ok, check all events, check for idle (and mark us sleeping 1449 * so as not to count towards the load average).. 1450 */ 1451 set_current_state(TASK_INTERRUPTIBLE); 1452 apm_event_handler(); 1453 } 1454 remove_wait_queue(&apm_waitqueue, &wait); 1455 }
-- Thanks, Sudheer
* Please do not print this email unless it is absolutely necessary. *
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Mon, Mar 7, 2011 at 9:42 AM, piyush moghe <pmkernel@gmail.com> wrote:
Hi Sudheer, If you see there is a schedule_timeout function called with some timeout so if you receive any signal ( handled by apm_event_handler ) before the timeout value it will be woken up and if it receives no signal before timeout value than scheduler will move this to RUNNABLE state again. Regards, Piyush
On Thu, Mar 3, 2011 at 5:20 PM, <sudheer.divakaran@wipro.com> wrote:
Hi,
I had asked a similar question before, but I've some doubts regarding the correctness of the following code. Please see the following code snippet from the file linux-2.6.37/arch/x86/kernel/apm_32.c. This is the core function of apm thread.
Question: Suppose the apm thread has just completed execution of the line 1442 and the scheduling happens for some reason, AFAIK, since the apm thread's state has been set to TASK_INTERRUPTIBLE, it will be removed from the run-queue. So there is a chance for the apm thread to remain suspended indefinitely as nobody is there to wakeup the apm thread, correct?
I'm asking this because the same function has been given as an example in the following link and would like to confirm the accuracy of the example.
http://www.linuxjournal.com/node/8144/print
1437 static void apm_mainloop(void) 1438 { 1439 DECLARE_WAITQUEUE(wait, current); 1440 1441 add_wait_queue(&apm_waitqueue, &wait); 1442 set_current_state(TASK_INTERRUPTIBLE); 1443 for (;;) { 1444 schedule_timeout(APM_CHECK_TIMEOUT); 1445 if (kthread_should_stop()) 1446 break; 1447 /* 1448 * Ok, check all events, check for idle (and mark us sleeping 1449 * so as not to count towards the load average).. 1450 */ 1451 set_current_state(TASK_INTERRUPTIBLE); 1452 apm_event_handler(); 1453 } 1454 remove_wait_queue(&apm_waitqueue, &wait); 1455 }
-- Thanks, Sudheer
Hi, My question was the apm thread getting scheduled out of run queue at apm_32.c line no 1443. i.e., for(;;), just after executing the line 1442, i.e., set_current_state(TASK_INTERRUPTIBLE); In this case, AFAIK, schedule_timeout(APM_CHECK_TIMEOUT) will not be executed as the apm thread will not be returned to the run queue. CMIIW. -- Thanks Sudheer
On Mon, Mar 7, 2011 at 10:09 AM, Sudheer <inbox1.sudheer@gmail.com> wrote:
On Mon, Mar 7, 2011 at 9:42 AM, piyush moghe <pmkernel@gmail.com> wrote:
Hi Sudheer, If you see there is a schedule_timeout function called with some timeout so if you receive any signal ( handled by apm_event_handler ) before the timeout value it will be woken up and if it receives no signal before timeout value than scheduler will move this to RUNNABLE state again. Regards, Piyush
On Thu, Mar 3, 2011 at 5:20 PM, <sudheer.divakaran@wipro.com> wrote:
Hi,
I had asked a similar question before, but I've some doubts regarding the correctness of the following code. Please see the following code snippet from the file linux-2.6.37/arch/x86/kernel/apm_32.c. This is the core function of apm thread.
Question: Suppose the apm thread has just completed execution of the line 1442 and the scheduling happens for some reason, AFAIK, since the apm thread's state has been set to TASK_INTERRUPTIBLE, it will be removed from the run-queue. So there is a chance for the apm thread to remain suspended indefinitely as nobody is there to wakeup the apm thread, correct?
I'm asking this because the same function has been given as an example in the following link and would like to confirm the accuracy of the example.
http://www.linuxjournal.com/node/8144/print
1437 static void apm_mainloop(void) 1438 { 1439 DECLARE_WAITQUEUE(wait, current); 1440 1441 add_wait_queue(&apm_waitqueue, &wait); 1442 set_current_state(TASK_INTERRUPTIBLE); 1443 for (;;) { 1444 schedule_timeout(APM_CHECK_TIMEOUT); 1445 if (kthread_should_stop()) 1446 break; 1447 /* 1448 * Ok, check all events, check for idle (and mark us sleeping 1449 * so as not to count towards the load average).. 1450 */ 1451 set_current_state(TASK_INTERRUPTIBLE); 1452 apm_event_handler(); 1453 } 1454 remove_wait_queue(&apm_waitqueue, &wait); 1455 }
-- Thanks, Sudheer
Hi, My question was the apm thread getting scheduled out of run queue at apm_32.c line no 1443. i.e., for(;;), just after executing the line 1442, i.e.,
set_current_state(TASK_INTERRUPTIBLE);
In this case, AFAIK, schedule_timeout(APM_CHECK_TIMEOUT) will not be executed as the apm thread will not be returned to the run queue. CMIIW.
-- Thanks Sudheer
Hi, I did some more googling and found a similar thread http://fixunix.com/linux/7425-schedule_timeout-doubt-possible-infinite-sleep... quoting from the link, [quote-] If I understand it correctly, when a preemption occurs, the PREEMPT_ACTIVE bit gets added to the thread's preempt_count; this happens in preempt_schedule / preempt_schedule_irq. These then call schedule(), which checks for PREEMPT_ACTIVE being set in the count and if it's set, it *doesn't* call deactivate_task(), which leaves the thread on the active list. [-quote] So if an interrupt occurs, the thread will not be pre-empted since the PREEMPT_ACTIVE bit has been set. I was not sure about the PREEMPT_ACTIVE bit. -- Thanks Sudheer
hi All, I am writing High performance network file system. An independently running kernel thread always multicast/unicast file system data over the network. I need to transfer user updated file system data/metadata to kernel thread. what is the best method to tranfer data from file system to running kernel thread ? Can I use workqueues ? Is there any recommended approach which is more compatible with future kernels ? __ Tharindu "R" Bamunuarachchi.
participants (4)
-
piyush moghe -
Sudheer -
sudheer.divakaran＠wipro.com -
Tharindu Rukshan Bamunuarachchi