[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?

    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.



    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:3.090 / U:0.380 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site