Messages in this thread | | | Date | Mon, 24 Jan 2000 01:04:38 -0600 (CST) | From | Brian Hurt <> | Subject | Re: 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |