Messages in this thread | | | Date | Sun, 18 Jul 1999 22:07:21 +0200 | From | Andi Kleen <> | Subject | Re: kernel thread support - LWP's |
| |
On Sun, Jul 18, 1999 at 09:32:53PM +0200, Alon Ziv wrote: > 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).
With sigqueueinfo:
new_tid = clone(...) sigwaitinfo( ..., &info ) if (info.si_errno) { ... } return;
thread: info.si_errno = sched_setscheduler(getpid(), ...) sigqueueinfo(parent, &info);
Which is two context switches, where one is "hidden" (the thread has not to wait for the parent to run, so it can happily complete its time share). With CLONE_SUSPEND the same hidden context switch is there too (you have to switch back to the parent sooner or later to process the return of pthread_create)
Also with the lazy tlb flushing 2.3 has now a context switch between threads that share VM is not much more than a function call now. And system calls itself are rather cheap in Linux, forget the old Solaris think where they are very expensive :)
-Andi -- This is like TV. I don't like TV.
- 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/
| |