[lkml]   [2000]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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
    > Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.026 / U:152.664 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site