>
> > 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/