Linux scheduler, overscheduling performance, threads

[Brian Hurt]

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