[lkml]   [1999]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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) {
> if (signal_pending(prev)) {
> prev->state = TASK_RUNNING;
> break;
> }
> + /* fall through */
> + 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);
> }
> 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

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


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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.049 / U:4.820 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site