Thank you for your kind description.
Since I just started learning the linux kernel, I didn't get used to
learn with parsing it.
Now things got to be nearly clear.
When I write a kernel thread without sleep()-family syscall to block, I
have to write a code like a following, right?
set_task_state(xxx, TASK_INTERRUPTIBLE);
add_wait_queue(&xxx, &xxx);
schedule();
Anyway, I'm trying to write a kernel thread from now on!
Thanks,
Shinpei Kato.
On Fri, 31 Oct 2003 20:46:06 +0100
Angelo Dell'Aera <buffer@antifork.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 31 Oct 2003 21:43:21 +0900
> Shinpei Kato <shinny@j02.itscom.net> wrote:
>
>
> >> In 2.4, a process running in the kernel (whether its a normal
> >> process or a kernel thread) cannot be preempted. It only
> >> relinquishes the processor when it voluntarily does so. >
>
> >You mean a process running in the kernel would be never preempted
> >unless it relinquishes the processor voluntarily?
> >If so, I get to have one concern. There are several kernel threads
> >created at the beginning of kernel processing, aren't there? For
> >instance, keventd or kapm, etc.
> >How are they scheduled? I mean how they are switched to another
> >kernel thread if they doens't have I/O-block or any other block?
> >Do they have to relinquish the CPU share time voluntarily? But they
> >wouldn't know when to relinquish, would they?
>
>
> A kernel thread can simply be viewed as a process without user space
> context. If you look it in this manner it's difficult not to
> understand that a kernel thread is "passed through the scheduler" just
> like any other process. For understanding it, take a look at the core
> of keventd which is the kernel thread which runs the schedule task
> queue.
>
>
> /*
> * If one of the functions on a task queue re-adds itself
> * to the task queue we call schedule() in state TASK_RUNNING
> */
> for (;;) {
> set_task_state(curtask, TASK_INTERRUPTIBLE);
> add_wait_queue(&context_task_wq, &wait);
> if (TQ_ACTIVE(tq_context))
> set_task_state(curtask, TASK_RUNNING);
> schedule();
> remove_wait_queue(&context_task_wq, &wait);
> run_task_queue(&tq_context);
> wake_up(&context_task_done);
> if (signal_pending(curtask)) {
> while (waitpid(-1, (unsigned int *)0, __WALL|WNOHANG) > 0);
> spin_lock_irq(&curtask->sigmask_lock);
> flush_signals(curtask);
> recalc_sigpending(curtask);
> spin_unlock_irq(&curtask->sigmask_lock);
> }
> }
>
> As you can see, when keventd is scheduled, it sets its state to
> TASK_INTERRUPTIBLE, it adds itself in the context_task wait queue. Do
> not consider the test done by TQ_ACTIVE now. So let's suppose
> curtask's state is TASK_INTERRUPTIBLE.
>
> After doing it, it calls schedule() and so it relinquishes the CPU.
> In this moment, keventd is not schedulable since it is in
> TASK_INTERRUPTIBLE state. It will become schedulable when
> someone/something add a task to the schedule task queue so changing
> keventd state.
>
> Let's see it. F.e. a driver code calls schedule_task().
>
> int schedule_task(struct tq_struct *task) {
> int ret;
> need_keventd(__FUNCTION__);
> ret = queue_task(task, &tq_context);
> wake_up(&context_task_wq);
> return ret;
> }
>
> It calls queue_task() which simply enques the task and then wake_up().
> This last function has the effect of setting keventd's state to
> TASK_RUNNING (please walk by yourself through kernel/sched.c).
>
> So when there's a scheduled task, keventd MAY be selected by the
> scheduler. When it will be scheduled in, it will simply run all the
> enqueued tasks and will repeat the same steps until your machine is
> up.
>
> Hope this helps.
>
> Regards.
>
>
> - --
>
> Angelo Dell'Aera 'buffer'
> Antifork Research, Inc. http://buffer.antifork.org
>
> PGP information in e-mail header
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQE/orv+pONIzxnBXKIRAoScAJ9x0OHo0dkIgdyDRtNinPiyIBi8HQCeIKrv
> SfCzKQ7lrk3LL57D13dJSJs=
> =LurC
> -----END PGP SIGNATURE-----
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
