Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Running 100,000 Parallel Threads 409

Posted by michael from the when-one-isn't-enough dept.
An anonymous reader writes "This story explains how the latest Linux development kernel is now able to start and stop over 100,000 threads in parallel in only 2 seconds (about 14 minutes 58 seconds faster than with earlier Linux kernels)! Much of this impressive work is thanks to Ingo Molnar, author of the O(1) scheduler recently merged with the 2.5 Linux development kernel."
This discussion has been archived. No new comments can be posted.

Running 100,000 Parallel Threads More

Running 100,000 Parallel Threads

Comments Filter:

  • Hold this thread while I walk away (Score:3, Funny)

    by DoctorHibbert ( 610548 ) on Sunday September 22, 2002 @12:27AM (#4305844)
    The linux song

  • 100,000 Linux threads (Score:5, Funny)

    by Anonymous Coward on Sunday September 22, 2002 @12:31AM (#4305855)
    this image springs to mind [discover.com]
  • It takes two seconds to start 100,000 threads???? Piff! With my ME computer, It doesn't matter how many parallel threads I am running... I can stop them all instantly by simply attempting to use my computer :P.

  • I'm only a humble C programmer, but.... (Score:4, Interesting)

    by cdrobbins ( 603631 ) on Sunday September 22, 2002 @12:34AM (#4305867)
    And this is great news, and, indeed, impressive. But my question is, what (if any) change is this going to make to my daily use of linux (for gcc, reading slashdot, and that's about it...) Am I going to notice any performance differences?
    • Just wait until Spyware For Linux(TM) comes out... With Bonzai Buddy For Linux(TM), Real Center For Linux(TM), XMMS Agent(TM), Linux Messenger(TM), Linux Update(TM), and FindFast for OpenOffice.org(TM). Then you will know why 100,000 parallel threads in two seconds is a good thing :P.
    • Java likes to run many threads very cavalierly, so it's likely to help there somewhat.

    • Re:I'm only a humble C programmer, but.... (Score:5, Informative)

      by bm_luethke ( 253362 ) <luethkeb@nOspam.comcast.net> on Sunday September 22, 2002 @01:11AM (#4305967)
      probably none. On the other hand the field I work in (high performance computing) this will be a great help. Currently we are running a 500,000 processor simulation on a four node cluster, startup and running both is a pain. Remeber, on of the great things about linux is some of the neat/usefull applications being ran on it (human genome, nuclear simulations, fluid simulations). Windows is a toy and geared toward "normal" users (read very few threads not processor intensive). Linux is more of a workhorse (many threads, computationally expensive, and high uptimes). While there are exceptions to this look at advances such as this in that light. And finally, just because you won't use it compiling a kernel doesn't mean it's not needed.
    • But my question is, what (if any) change is this going to make to my daily use of linux... Am I going to notice any performance differences?

      My question is why does the multithreading in Mozilla suck so badly on Linux and will this help it?
    • But my question is, what (if any) change is this going to make to my daily use of linux...?

      Well, for one thing, you're now going to have to start typing a helluva lot faster. The machine is not going to slow you down. ;-)

      In truth, this is great news for those running servers but you probably won't notice much of a difference on a desktop, barring a few really thread heavy applications. UML (User Mode Linux) is one notorious example.
    • The performance improvement won't mean much, but the POSIXization of the thread library might make a difference. Linux's thread support has up till now been pretty kludgy (signal handlers per-thread instead of per-process, wrong coredumps, etc.), and that made things like debugging threaded programs difficult; you may have run into this with gdb or whatever. Now that the Right Things have been coded in all over the map (kernel/libc/gcc/etc), we can drop the kludge and start doing it right.

  • If you want to destroy my boxen. . . (Score:3, Funny)

    by endeitzslash ( 570374 ) on Sunday September 22, 2002 @12:35AM (#4305870)
    Launch 100,000 threads while I walk away. . .

    OK I'll shut up now.

  • Parallelism (Score:5, Interesting)

    by inkfox ( 580440 ) on Sunday September 22, 2002 @12:36AM (#4305874) Homepage
    This is very cool; but does it scale to multiple CPU systems? More and more, SMP, split-bus and multi-core architectures are going to be taking over. If this holds up in those environments, Linux may actually have a leg up on some of the dedicated task heavyweights.

  • Great news! (Score:2, Funny)

    by zensonic ( 82242 )
    So now I'm able to open up 100.000 pr0n pictures in just 2 sec. Ubercool ;-)
  • 0 to 100,000 in 2 seconds. Let me try t h i s.. Ww ait w h y is ever yth ing soo slooooow...
  • Will this allow a computer to survive some DoS attacks? It should be able to cope with the influx a bit better, correct? Am I being insane?

  • Sounds cool, but all I could think of... (Score:5, Funny)

    by Geek Tragedy ( 134539 ) on Sunday September 22, 2002 @01:04AM (#4305951)
    "Hello, my name is Ingo Molnar. You killed -9 my process: prepare to die."

    Sorry, had to :P

  • NOOO!!!!! (Score:3, Funny)

    by Monkelectric ( 546685 ) <slashdot AT monkelectric DOT com> on Sunday September 22, 2002 @01:07AM (#4305958)
    At school (before I graduated so long ago) we would "fork bomb" the compute servers [ while(1) do { fork(); } ] in an attempt to extend deadlines or simply be assholes :)
    • Hehehe I had a classmate do that accidentally.

      One of our final projects was to impliment our own shell. This would of course necessitate a fork() command... he hadn't checked conditions quite right and managed to use up all the resources for his account. Fortunately someone had set the Ultrix (Unix on VAX) system up with a little intelligence. He only bombed his own account and had to get the Prof. to go in and kill the out of control Shell :)

      I on the other hand merely got half-baked tokenizing. Great teacher (pity the disbanded the Comp-Sci department around us).

    • Re:NOOO!!!!! (Score:5, Funny)

      by ez76 ( 322080 ) <slashdotNO@SPAMe76.us> on Sunday September 22, 2002 @01:50AM (#4306049) Homepage
      I am replying pre-emptively to dissuade the AC's who would otherwise reply to you and point out that your post should not have been modded funny because this innovation would not prevent fork() bombing because it involves spawning threads and not processes.

      I am further replying pre-emptively to dissuade the AC's who would otherwise reply to me and point out my egregious abuse of run-on sentences.

      I am further replying pre-emptively to dissuade the AC's who would otherwise reply to me and point out my egregious abuse of +1 bonus.

      I am further replying pre-emptively to dissuade the AC's who would mod this post down as off-topic because they do not get the parallel allusion to fork-bombing.

    • Re:NOOO!!!!! (Score:3, Funny)

      by AJWM ( 19027 )
      I did something like that back in my school days on a dual-CPU Burroughs B6700, but with a twist: Each process forked itself twice, then waited. When it received a signal about a child process being killed, it spawned two more. I had a sleep of a few seconds or so in there so it didn't grow too fast.

      The fun part of that was when the system operators saw the processes replicating like crazy and started to kill them, that made it worse.

      Another fun trick with that machine was to set up a circularly-linked list and invoke the LLLU (linked list lookup) instruction on it...

      (Yeah, stupid things to do. At least I only did them during relatively quiet times.)
    • I ran this in DOS:

      prompt "Enter Password:"

      No one could figure out that all i did was change the prompt from "$P$G" to that, and everyone was asking what the password was. haha, good old teacher was infinitely frustrated as well! IT WAS BEAUTIFUL.

      I got kicked out for a year (not beautiful).
      • Some guys I know copied a Windows error dialog box and set it as a background image for the desktop, centered.

        Imagine the poor victim vainly clicking on the buttons, and getting more and more worried. Said victim actually rebooted the machine to see it reappear, and was not happy when he started to notice the sniggering bunch behind him...

        For example pic:
        http://www.adobe.com/support/techguides/oper atings ystem/windows/winerrors.html
        Probably want to replace CCmail with Explorer or something more dear to heart ;).

        I also installed a bluescreen STOP screensaver on April Fool's day on a colleague's PC. Heh, he was shocked enough to actually called another colleague over and made the usual worried mumbles.

        http://www.sysinternals.com/ntw2k/freeware/blues cr eensaver.shtml

        Since I had admin privs, I was also tempted to have ad.doubleclick.net and similar dns names to resolve to a private webserver which served out custom banner ads.

        Wonder how users would take it if they see the "Staff Meeting at 2pm banner ad". Or "Company Slogan here". Or "Big boss is watching you!". Or for search result sensitive ads: "Stop downloading mp3s/movies/porn!"

        I could actually justify that as a useful application. It's probably more useful than a doubleclick ad...

        But I'd probably need the 100K parallel thread kernel to serve up all those ad banners :).

        Bwahaha!
        Link.

  • Windows (Score:3, Interesting)

    by jeffbru ( 170238 ) on Sunday September 22, 2002 @01:08AM (#4305960)
    Just out of curiousity, how does the benchmark in windows compare?

    • Re:Windows (Score:2, Troll)

      by CoolVibe ( 11466 )
      Oh, I'll bet Microsoft could rig an system without the graphics, network, most driver subsystems and the GUI stuff to skimp on overhead and winge their way to a higher number of parallel threads in less time.

      Or they could just blatantly pay some other company that does "independant testing" *cough*mindcraft*cough to lie about it :)

      • Re:Windows (Score:2, Insightful)

        by Courageous ( 228506 )
        It is *impossible* to even allocate more than about 31,000 threads under windows on 32 bit machines. You simply CAN'T do it. The minimum thread stack size is 1 64KB page. You an only address 2GB of memory on a 32 bit windows OS. Do the math.

        C//
        • Two nitpicks:
          you can address 3GB with the /3GB switch :)
          you can address significantly more with AWE/PAE, but i dont know that you can use that additional memory for thread stacks.

          Just FYI, Yesterday i had SQL server 2k running with 1914 threads ( in AWE mode)

    • Re:Windows comparison (Score:3, Interesting)

      by pVoid ( 607584 )
      Very interestingly enough, either windows has a quota, or some sort of memory leak or something...

      Max I can create in a process is 2031 threads... That being done in 700ms.

      It's odd cause I can create more if I run several processes. It doesn't look like the kernel is choking on thread creation...

      will investigate more.

      • Re:Windows comparison (Score:4, Informative)

        by Courageous ( 228506 ) on Sunday September 22, 2002 @01:59AM (#4306066)
        Very thread uses a minimum of *1 PAGE* of reserve memory for its statck, which is 64K. However, you have to go out of your way to use less than 1 megabyte of reserve memory. Since only 2GB of reserve memory (addressable memory) is available to user applications, this would fit your 2000 thread figure like a glove.

        C//

  • whoa! (Score:4, Funny)

    by RestiffBard ( 110729 ) on Sunday September 22, 2002 @01:27AM (#4306003) Homepage
    I have no idea what the hell you're talking about but it certainly sounds impressive. :)

  • Great (Score:3, Funny)

    by C0D3X ( 300627 ) on Sunday September 22, 2002 @01:28AM (#4306004)
    Now we finally have the power to run 99,999 pop up ads when we visit that pr0n site
  • Normally I am of the "use only as many threads as CPUs" school of thought, but I can think of a reason to use 100,000 threads - imagine a large FTP server, or a multi-homed HTTP server, where you need to provide each connected user with his own set of access privileges or filesystem context. A one-thread-per-connection server may be the easiest way to build security into the system.

    • Re:Possible use (Score:2, Informative)

      by vsync64 ( 155958 )
      Except that threads, as far as I am aware, share the same address space. Multiple processes need to arrange to share memory, and therefore are less likely to trample on one another or careen out of control.
      • of course the penalty you pay for this is that fork() is expensive, and shared memory is a finite system resource. try the command "ipcs" on a sys-v type box.

        It is also generally the case that switching between processes is more expensive than switching between threads.

        to the parent poster : 1 thread per connection is a pretty naive way to do it, but its got advantages - simplicity. It's a moot point since on a stock OS you'd run out of socket descriptors long before you'd run into a thread-count maximum.

    • Uber monster sim program, with a city full of residents, each run by a thread.

    • Re:Possible use (Score:4, Insightful)

      by be-fan ( 61476 ) on Sunday September 22, 2002 @01:45PM (#4307681)
      "use only as many threads as CPUs"
      >>>>>>>>
      Then please stay away from my GUI apps. I hate those UNIX grognards that come from that school of thought, then try to code GUI applications with only one thread and end up with apps that can't update the GUI while doing I/O. On my 300 MHz PII, that particular trait made Galeon unusable. It had one rendering thread for all the tabs, so when I was loading a complex page like /. in another tab, whatever tab I was actually reading would freeze up.

  • nice, but... (Score:4, Interesting)

    by g4dget ( 579145 ) on Sunday September 22, 2002 @02:00AM (#4306069)
    It's nice that the Linux kernel can handle that many threads. But user level threads generally are even more lightweight, and high performance implementations like those on Solaris provide both user level and kernel level threads and map the former onto the latter. Is Linux going to get something similar? Is Sun perhaps donating their implementation? Or are these new kernel threads so lightweight and quick that they are competitive with Solaris on their own, without the mess and complication of adding user level threads?

    • Re:nice, but... (Score:4, Informative)

      by Magnus Reftel ( 143 ) on Sunday September 22, 2002 @04:50AM (#4306288)

      According to a mail from Ingo Molnar halfway down the linked article, M:N threading doesn't really solve the real problem - it's good at switching back and forth between running threads, but the real reason for having very large amounts of threads (be they kernel or user space threads) to begin with, is to do IO, and for that, there is no real advantage of user space threads.

      More info on the 1:1 vs M:N issue can be read in the white paper [redhat.com]

      • Thanks for the pointer. Sounds like they went with 1:1 for a good reason. I always thought of M:N threading as kind of a kludge and not entirely trustworthy anyway (scheduling and I/O become rather iffy).
    • User-level threads cannot take advantage of multiple CPUs. True, they are somewhat faster on a single CPU system due to lower overhead, but that's all they are good for.

  • How will this affect Mozilla, OpenOffice... (Score:4, Interesting)

    by 3770 ( 560838 ) on Sunday September 22, 2002 @02:01AM (#4306072) Homepage
    How will this change affect Mozilla, the Sun JVM and OpenOffice, for instance.

    While it probably is generally true that it will take some time for most applications to start using the new threading model some larger applications could support it fairly soon.

    Can we expect these applications to be adapted to the new threading model some time soon, and how will it affect performance?
  • ...will start writing horrible monsters running hundreds and thousands of threads, and their creations will suffer from all other shortcomings of that decision.

  • big deal (Score:4, Funny)

    by leomekenkamp ( 566309 ) on Sunday September 22, 2002 @02:53AM (#4306150)
    100.000 threads? What nonsense; everybody knows that no computer would ever use more than 640.
  • It looks like speed isn't the only improvement they've made with this library. From the notes:

    " - - libpthread should now be much more resistant to linking problems: even if the application doesn't list libpthread as a direct dependency functions which are extended by libpthread should work correctly."

    This ought to be a big help for those of us who write plug-in modules for servers like Apache 1.x and PHP. The existing thread library doesn't work properly unless the program executable explicitly links to it, which means that my shared libraries can't take advantage of standard thread management such as pthread_atfork().
  • Given that Apache 2.x can utilise threads as well as processes, does this mean that you can configure a large web server with, say "MaxSpareThreads 1000000" so that you can cope when you're slashdotted ;-)?

  • 100000?! (Score:3, Redundant)

    by thelexx ( 237096 ) on Sunday September 22, 2002 @03:23AM (#4306174)
    640 should be enough for anybody!

    LEXX
  • Combine this with Apache2's Multi-threaded or Hybrid MPM and you'll have a heck of a web-server!

  • POSIX compliance ahead? (Score:2, Informative)

    by rkit ( 538398 )
    Scalability is a good thing, no doubt about that. However, there is another aspect that should be pointed out: the current thread API in linux is quite different from the POSIX specification and somewhat crufty. Just to mention the biggest problems:
    missing cancellation points: testing whether a thread has been cancelled should be done in lots of system calls, but linux pthreads do not support this. Instead, you have to call pthread_testcancel() before and after every such call. A real drag.
    signal handling: linux pthread signal handling is very different from the POSIX specification. However, proper signal handling is crucial for any real world application.
    fork() will not work as expected. This is a real nuissance if you want proper daemon behaviour for your application.
    documentation of linux-specific behaviour is poor. As a result, most of the existing literature on thread programming is pretty useless for linux.
    All these points can be worked around, for sure. Nevertheless, it makes writing portable software a nightmare. Porting threaded software to linux, well ... All in all, linux threads really need much better integration with the standard system API. A lot of applications could profit from multithreading. Just think of GUI responsiveness. Also, using threads makes some programming tasks much easier. No need for asynchronous hostname lookup, for example.
    A solid, well documented, standard conforming threads implementation will make linux a much nicer environment for serious programming than it already is. I am really looking forward to this.
    • Nobody ever said that linux-specific behavior is POSIX-compliant. Last I heard, POSIX is not about the specifics of any given UNIX-compatible or class of system. Rather, it attempts to be the abstraction and distillation of those class of systems, as codified by The Open Group. Please correct me if I am wrong in this idea. Linux simply simply "aims to be..." POSIX-compliant, as promulgated by the LSB, the FHS, et al. --

      That all said, I totally agree with you -- especially regarding cancellation points, fork(), and documentation.

      Please bear in mind that much of this behavior will be inherited from whatever libc it it compiled against. IMO, this simply shows the power of C, nothing else.

      The above scenario simply points out the differences between OpenGroup/POSIX and GNU/FSF... if things like that "bug" you (no pun intended, seriously), then perhaps you should recompile with whatever "-- posixly-correct" options you have available.

      And yes, I have a copy of the SUSV3 spec right here, in fact.
    • See subject. A useful 'heads up' post for folks like myself who tend to assume that Linux will follow the general Un*x-family behaviours we're familiar with from the commercially-sold variants.

      And yes, I would of course ;) check this assumption if I were to do some significant implementation for the Linux platform.

  • NGPT (Score:2)

    by p3d0 ( 42270 )
    Then, with NGPT [ibm.com] (Next-Generation Posix Threads), those 100,000 threads would be in user space and may be even cheaper.
  • From the ensuing discussion on the list:
    Ingo:...Anton tested 1 million concurrent threads on one of his bigger PowerPC boxes, which started up in around 30 seconds. I think he saw a load average of around 200 thousand. [ie. the runqueue was probably a few hundred thousand entries long at times.]
    Wow.. this is pretty good.The ability to spawn & run 1 million concurrent threads should keep even the most demanding users happy for a few years...

    OTOH, I hope this post doesn't become the butt of jokes a few months from now ("and you thought 1 million was a lot! Ha! My Palm 5000XL does more than that!")...

  • Linus didn't think much of O1 scheduler (Score:3, Interesting)

    by jelle ( 14827 ) on Sunday September 22, 2002 @05:22PM (#4308449) Homepage
    I remember that Linus made a remark that he tought that the O1 scheduler wouldn't impact Linux much at all, and that its development would not be a biggie for Linux, downplaying the importance of what it can achieve. Go Ingo for keeping at it!

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close