Messages in this thread | | | Date | Sun, 18 Jul 1999 22:32:53 +0300 (IDT) | From | Alon Ziv <> | Subject | Re: kernel thread support - LWP's |
| |
On Sun, 18 Jul 1999, Andi Kleen wrote:
> > > code I've orignially posted, The code size increase in the kernel is > > minial. What can possibly be wrong with this? > > What I didn't like with your idea is that it is 100% equivalent (even from the > work the kernel has to do) to kill(getpid(), SIGSTP); at the beginning > of the child. >
It's only _semantically_ equivalent (that is, it's the same from the process's POV). But it has two context switches which could have been avoided, so its performance will _surely_ be worse.
And no, the kernel _will_ need to do more in the `kill()' case--- with CLONE_SUSPEND, the complete work to create a new thread is like
Original thread: - allocate new stack - new_tid = clone(...|CLONE_SUSPEND|...) - (update thread tables & related stuff) - sched_setscheduler(new_tid, ...) - kill(new_tid, SIGCONT) New thread: - just start running...
Total 3 syscalls, 1 context switch (on the `kill()').
If we use the trampoline approach, we get:
Original thread: - allocate new stack - new_tid = clone(...) - waitpid(new_tid, WUNTRACED) - (update thread tables &c) - kill(new_tid, SIGCONT) New thread: - sched_setscheduler(new_tid, ...) - kill (new_tid, SIGSTOP)
A total of 5 syscalls, and 3 context switches. (We'd get the same with sigqueueinfo and sigwaitingo, BTW).
-az
------------------------+---------------------------------------------------- . __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work) _| / | email: alonz@usa.net / | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel ------------------------+---------------------------------------------------- <<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |