Messages in this thread | | | Date | Thu, 20 Jan 2000 22:57:07 -0600 (CST) | From | Brian Hurt <> | Subject | Re: Linux scheduler, overscheduling performance, threads |
| |
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.
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.
VolanoMark is a real application, and is really sold. People do really write programs like this- except that they're generally for the Enterprise market. The question here is if Linux is just a desktop/small server OS, or if it's also going be an enterprise OS? This isn't meant to be a snide or insulting question- I'd actually _prefer_ Linux to simply be the best desktop/small server OS out there. But if Linux is going to play in the enterprise market- running the same programs and doing the same jobs (albeit slower and cheaper) as that Enterprise 10000 server, it had better be ready to deal with applications that spawn thousands of threads.
You're not going to be able to reeducate the hoards of computer pundits and anonymous cowards trumpeting Linux as the one true OS (or disparaging it in favor of this other one true OS)- but the kernel developers should know the answer.
On Fri, 21 Jan 2000, Ingo Molnar wrote:
> > On 20 Jan 2000, H. Peter Anvin wrote: > > > > So it is a net gain on any machine with 8 or more running processes. > > > Pretty much all of my machines fall in that range and most of them > > > are personal workstations. > > > *RUNNING* processes? Most desktops don't have even one running > > process most of the time. > > yep, many people i believe are missing the point. Linux schedules just > fine if there are 20000+ threads running: > > moon:~/l> ps aux | wc -l > 20137 > moon:~/l> ./lat_ctx -s 0 2 > "size=0k ovr=2.82 > 2 2.08 > > (ie. on a system with 20137 threads created we schedule from one process > to another in 2.08 microseconds. This is exactly as fast as on a system > with only a few processes.) > > the issue is, how many threads are running at once. If it's much more than > the number of processors then the system is either 1) hopelessly > overloaded and needs a hardware upgrade 2) the application (or kernel) for > some reason is marking too many threads to run, and this creates > overscheduling situations. Such situations have to be avoided, but > debugging such situations is not simple. Nevertheless we cannot tell in > advance wether it's the application's or the kernel's fault. But the most > important thing is that it's definitely not the scheduler's fault. Dont > shoot the scheduler, it's just he messanger. > > -- 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/ >
- 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/
| |