Linux scheduler, overscheduling performance, threads

[David Schwartz]

> 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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/