Re: Asynchrony (was Re: Locking a process or thread onto a specific CPU)
Alexander Kjeldaas (astor@fast.no)
Fri, 19 Feb 1999 18:21:28 +0100
On Fri, Feb 19, 1999 at 02:50:40AM +0000, David Wragg wrote:
>
> To have a substitute task get woken with a signal just needs something
> like:
>
> pseudo-diff against kernel/sched.c, line 670 in 2.2.1
> switch (prev->state) {
> case TASK_INTERRUPTIBLE:
> if (signal_pending(prev)) {
> prev->state = TASK_RUNNING;
> break;
> }
> + /* fall through */
> + case TASK_UNINTERRUPTIBLE:
> + if (prev->substitute) {
> + spin_unlock_irq(&runqueue_lock);
> + kill_proc(prev->substitute,
> + prev->substitute_sig, 0);
> + spin_lock_irq(&runqueue_lock);
> + prev->subsitute = 0;
> + }
> + /* fall through */
> default:
> del_from_runqueue(prev);
> case TASK_RUNNING:
> }
>
> Plus a new prctl option to set the substitute and substitute_sig for a
> task. Probably support for passing the pid of the about-to-sleep task
> to the substitute as signal info would be nice also.
>
> Is this actually useful? Well, the cost of the kill_proc is low; we're
> about to do a task switch anyway.
>
> For the userspace thread scheduler Jamie mentions, the substitute
> thread upon waking just calls the scheduler. It will even allow you
> attempt to do work while the original thread suffers a page-in. It
> should also be straightforward to implement a async IO API on top of
> it. The thread returning from the call to initiate IO may be a
> different task from the one that called it, but I think all the
> problems this causes can be worked around.
>
There is something else we might need as well: Yielding to a specific
process.
The problem manifests itself in large threaded programs. Say you have
a couple of hundred threads in a program. In these programs, there
will always be some bottlenecks. Locks surrounding malloc() is a
typical example. Lots of processes will block trying to allocate
memory. After the process that has aquired the lock releases it, all
the other processes will be waked up, leading to a "thundering
herd"-problem exactly like the one happening for networking
applications. Now if we could yield explicitly to the first process
waiting for the lock, we would get acceptable performance again.
LinuxThreads seems to loose against FreeBSD user-land threads in this
regard.
astor
--
Alexander Kjeldaas, Fast Search & Transfer, Trondheim, Norway
-
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/