* scheduling - more doubts @ 2011-03-03 11:50 ` sudheer.divakaran at wipro.com 2011-03-07 9:42 ` piyush moghe 0 siblings, 1 reply; 5+ messages in thread From: sudheer.divakaran at wipro.com @ 2011-03-03 11:50 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110303/4de626d8/attachment-0001.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* scheduling - more doubts 2011-03-03 11:50 ` scheduling - more doubts sudheer.divakaran at wipro.com @ 2011-03-07 9:42 ` piyush moghe 2011-03-07 10:09 ` Sudheer 0 siblings, 1 reply; 5+ messages in thread From: piyush moghe @ 2011-03-07 9:42 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110307/0eea94db/attachment.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* scheduling - more doubts 2011-03-07 9:42 ` piyush moghe @ 2011-03-07 10:09 ` Sudheer 2011-03-14 6:24 ` Sudheer 0 siblings, 1 reply; 5+ messages in thread From: Sudheer @ 2011-03-07 10:09 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* scheduling - more doubts 2011-03-07 10:09 ` Sudheer @ 2011-03-14 6:24 ` Sudheer 2011-03-15 11:49 ` Tharindu Rukshan Bamunuarachchi 0 siblings, 1 reply; 5+ messages in thread From: Sudheer @ 2011-03-14 6:24 UTC (permalink / raw) To: kernelnewbies 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.html 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* scheduling - more doubts 2011-03-14 6:24 ` Sudheer @ 2011-03-15 11:49 ` Tharindu Rukshan Bamunuarachchi 0 siblings, 0 replies; 5+ messages in thread From: Tharindu Rukshan Bamunuarachchi @ 2011-03-15 11:49 UTC (permalink / raw) To: kernelnewbies 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-15 11:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AcvZmTBTVk7OqpC5TKq9iaODLGxmJA==>
2011-03-03 11:50 ` scheduling - more doubts sudheer.divakaran at wipro.com
2011-03-07 9:42 ` piyush moghe
2011-03-07 10:09 ` Sudheer
2011-03-14 6:24 ` Sudheer
2011-03-15 11:49 ` Tharindu Rukshan Bamunuarachchi
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).