[lkml]   [2000]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux scheduler, overscheduling performance, threads
I've given this thread up.  While I'm not convinced that there isn't a
problem, I am convinced that most people on this list are convinced that
there isn't. When/if it bites me, I'll write a patch and have real code
to show people. If it bites IBM before it bites me and they fix it, well
and good. So in a sense it isn't a problem- if it becomes one it can (and
will) get fixed.

On Mon, 24 Jan 2000, Ingo Molnar wrote:

> On Thu, 20 Jan 2000, Brian Hurt wrote:
> > Following this thread off and on since it's inception, and being a Java
> > programmer myself, can I offer some observations?
> >
> > 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. 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. Unfortunately, due to vagaries of the system, you will have
> > points when most of the threads become runnable at once.
> i believe you are confusing '2000 threads created and happily waiting
> blocked to do something' and the '2000 threads running' case. I
> specifically included a quick benchmark showing 20 thousand threads being
> around on my system and not impacting Linux scheduler performance the
> slightest. What i say is that more than nr_cpus*2 _running_ (ie. currently
> waiting for the CPU, not some other resource) threads are bad.
> -- mingo

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.117 / U:0.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site