Messages in this thread |  | | | From | "David Schwartz" <> | | Subject | RE: Linux scheduler, overscheduling performance, threads | | Date | Fri, 21 Jan 2000 11:34:18 -0800 |
| |
> Following this thread off and on since it's inception, and being a Java > programmer myself, can I offer some observations?
Ahh, a Java programmer, that explains it.
> Thousands of threads in a program is not unreasonable.
Thousands of threads of some kind in a program may or may not be unreasonable. Thounsands of kernel-scheduled threads is, unless the machine has thousands of processors.
> If you may want to > take full advantage of a 128 CPU machine, for example, you need _at_ > _least_ 128 threads.
No, you need 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.
If your kernel-scheduled threads spend most of their time blocking, then your program is misdesigned. You are wasting resources for no reason.
> Unfortunately, due to vagaries of the system, you will have > points when most of the threads become runnable at once.
This is only the case when you have a very bad threading architecture. For example, if you one-to-one map Java thread with LinuxThread, you will have this problem. The fault is not in Java, and it's not in Linux -- it's in the broken mapping.
> 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.
Right. The solution is to have kernel threads and to manage them wisely. Linux currently has everything you need to do this.
> 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.
Again, the fault is in the one-to-one mapping of Java threads (which are assumed cheap) and kernel threads (which are not). If someone writes a C or C++ application that uses way more threads than there are processors, that someone needs to be re-educated.
> 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.
Eh?
DS
- 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/
|  |