Re: kernel thread support - LWP's
Andi Kleen (ak@muc.de)
Sun, 18 Jul 1999 22:07:21 +0200
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/