Messages in this thread | | | Date | Fri, 19 Feb 1999 18:21:28 +0100 | From | Alexander Kjeldaas <> | Subject | Re: Asynchrony (was Re: Locking a process or thread onto a specific CPU) |
| |
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/
| |