Re: [Question] Some question about Ingo scheduler.

[liyu <liyu@ccoss.com.cn>]

Steven Rostedt Wrote:

> On Tue, 11 Oct 2005, liyu wrote:
>
>  
>
> > Hi, Steve:
> >
> >    Thanks for so detailed explain.
> >
> >    It seem I am not understand what is sleep and wakeup truly.
> >
> >    What's your mean of "in runqueue"? I think you mean the
> > task_struct is in one priority array (active or expired)
> > of one queue. the schedule() only can process task in runqueue.
> > In deactivate_task(), it will reset task_struct->array to NULL,
> > After call it, we can not wake up that task.
> >    
>
> Correct.  The active/expired arrays _are_ the run queue.
>
>  
>
> >    However, I read try_to_wake_up(), and found it can handle that case
> > which task_struct->array is NULL, it will be call activate_task()
> > to insert task to one runqueue. and default_wake_function() will
> > call try_to_wake_up(), so we still can wake up it.
> >    
>
> Exactly! :-)   try_to_wake_up _is_ what wakes up the task.  Now the
> problem is _who_ calls try_to_wake_up.  My example is about some task that
> initiates something that will happen and waits for it.  Like something
> writing to disk and waiting for the write to finish.  It waits for an
> interrupt or some service handler to do something.  The problem is that
> the logic that I showed, has to handle the case where the event happens
> before it goes to sleep (calls schedule).  Since the service provider is
> the one that wakes it up, if the event happens before it goes to sleep and
> the sevice provider already woke up the task (although it wasn't sleeping)
> it wont wake it up again.
>
> So, if the task is preempted in the TASK_UNINTERRUPTIBLE state and taken
> off the run queue (active/expired arrays), and since the event had already
> happened, _no_one_ will call try_to_wake_up on this task that is sleeping.
> And the task will stay sleeping and never wake up.
>
>  
>
> >    I am confused again. this quesion is more interesting and more.
> >    
>
> You're getting closer to understanding.  I can tell by your later
> questions ;-)
>
>  
>
> >    Wait for reply.
> >
> >    Good luck.
> >
> >
> > --liyu
> >
> >    
>
> -- Steve
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
hi, Steve:

   Thanks, your words make this more sense. :)

   The global process I understand is follow:

add_wait_queue(q, wait);

/*
*   service handler is waking up current task now, it so soon!
*   And the try_to_wake_up() will change task_struct->state to 
TASK_RUNNING.
*/

set_current_state(TASK_UNINTERRUPTIBLE); /* reset task_struct->state 
from TASK_RUNNING to TASK_UNINTERRUPTIBLE. */

if (!some_event) /* alreay wakeup, so some_event is true */
       schedule();

/*
*   preempt_schedule() is taking here!
*   current task will sleep forever without PREEMPT_ACTIVE check! 
because of it is removed
*   from runqueue, and none will wakeup it (bring it back to runqueue).
*/

set_current_state(TASK_RUNNING);
remove_wait_queue(q, wait);

In fact, your first reply already is very clearly, but I read too 
quickly to ignore something.

These code of only six lines imply so many secrets. All interesting came 
from it.

Happy everyday.

-liyu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/