scheduling - more doubts

scheduling - more doubts

[sudheer.divakaran at wipro.com]

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 

scheduling - more doubts

[piyush moghe]

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 

scheduling - more doubts

[Sudheer]

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

scheduling - more doubts

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

scheduling - more doubts

[Tharindu Rukshan Bamunuarachchi]

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.