[lkml]   [2000]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux scheduler, overscheduling performance, threads
Brian Hurt wrote:
> Thousands of threads in a program is not unreasonable. If you may want to
> take full advantage of a 128 CPU machine, for example, you need _at_
> _least_ 128 threads.

You want exactly 128 threads running, no more.

> If your threads spend most of their time blocking,
> you need even more threads, you need to overschedule, to make sure you
> generally have enough threads not blocking to make sure CPUs aren't going
> to waste.

You want threads that block to active new threads so there are still
exactly 128 running at a time.

> User level threads are not a full solution- they help, and are a good
> thing, but are not a silver bullet. The basic problem is that there are
> still ways for a process to block that can't be intercepted and "faked" by
> the user level threads- page faulting, for instance. And if a thread
> blocks, all threads that share that process are also blocked. Plus, all
> the problems and difficulties of scheduling are not removed, they're
> simply shoved onto the threading library.

That's all solved by having blocking threads activate another thread to
fill in the gap, and something to do the same in the reverse. But
no-one's written the code yet.

-- Jamie

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:56    [W:0.157 / U:2.808 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site