Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Gains Support for NUMA

Posted by CowboyNeal on from the big-iron-at-your-hip dept.

soosterh writes "CNet has an article about a NUMA patch from IBM. It says that the improvement adds some support in Linux for nonuniform memory access, or NUMA, a design for higher-end servers with many processors. Linus Torvalds, the original creator of the operating system and still its top authority, accepted the update this month into version 2.5, the current test version of the software."

84 of 143 comments (clear)

  1. Isn't there some other numa stuff already in? by eyez · · Score: 4, Insightful

    I thought that I'd seen some other NUMA stuff in previous runs of 'make menuconfig'-- Can anyone explain what's already there and what this patch adds?

    --
    get 0wned. irc.w30wnzj00.com
    1. Re:Isn't there some other numa stuff already in? by hansendc · · Score: 2, Informative

      NUMA refers to a wide range of features. Everything from multipatch networking or SCSI, to memory allocation, to placing processes close to "good" memory. This particular patch simply makes processes run on CPUs where they're likely to be close to memory which they will need.

    2. Re:Isn't there some other numa stuff already in? by Error27 · · Score: 3, Informative

      You are correct. The LWN article on this just became available to non-subscribers and you can read it here:http://lwn.net/Articles/20741/

      (BTW. Everyone should subscribe to LWN. It's an exceptional value)

    3. Re:Isn't there some other numa stuff already in? by Anonymous Coward · · Score: 1, Interesting

      Well, IBM has lots of scheduler experience. This is called processor affinity in the IBM world. Keep the process close to where its resources are.

  2. 32/64 by Overand · · Score: 1

    Will this help with both 32 bit and 64 bit desktop platforms? It seems that in the future there won't be much distiction between the current server machines and desktops...

    1. Re:32/64 by larien · · Score: 2, Informative
      I'd imagine it's mainly for 64-bit as that's the kind of systems which tend to ship with NUMA (usually with MIPS or Itanium). Without knowing more, I couldn't comment as to whether it will work under 32-bit or not, but I can't see how it would be so limited.

      Also, I seriously doubt if any desktop machine will use NUMA; it's primarily about systems which use system boards, where there are CPUs & RAM on a board which slots into the system & a CPU can access memory on a local board faster than that on other boards. Desktops tend to use one "system board" (i.e. the motherboard) so there isn't the difference in speed for accessing the data.

    2. Re:32/64 by hansendc · · Score: 2, Informative

      I'd imagine it's mainly for 64-bit as that's the kind of systems which tend to ship with NUMA (usually with MIPS or Itanium). Without knowing more, I couldn't comment as to whether it will work under 32-bit or not, but I can't see how it would be so limited.

      That is an incredibly naive comment. NUMA systems have been around for quite a while (think Sequent), the current generation of IBM x440 are NUMA. These are all 32-bit Intel architectures.

      This patch didn't even address memory, it only dealt with scheduling processes anyway.

  3. Imagine a beowulf... by Gordonjcp · · Score: 3, Informative

    Seriously, this is something that will close one of the last remaining gaps between Linux and Solaris. Not that it will do much good for 99% of users out there, but if you need this, you *really* need it.

    1. Re:Imagine a beowulf... by jedidiah · · Score: 1

      Why would anyone need to bother? If this is an IBM patch, then it likely means that Linux could just run on big IBM boxes (bare metal).

      Give Linux running on such boxes better process affinity and this could very well cause Solaris to be the OS that needs to catch up. Process affinity on E12K systems is simply attrocious.

      That is why I've been following the lastest SGI developments in this area with some anticipation.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    2. Re:Imagine a beowulf... by zevans · · Score: 1

      And close the gap between Linux and AIX - which is interesting when you consider:

      A) Where this patch has come from
      B) What the guts of the p690 look like
      C) What the guts of the x440 look like

      Death of AIX predicted. Film at 11.

      --
      "... and more and more now there are all kinds of electronic goodies available" -- Pink Floyd 1972
    3. Re:Imagine a beowulf... by Gordonjcp · · Score: 1

      I hate to break it to *you*, but I use Solaris and NetBSD daily. Furthermore, I was simply trying for a first post.

  4. And AMD... by addaon · · Score: 5, Informative

    And, of course, also support for the Hammer architecture, which is (smaller scale) NUMA. Each processor in an x86-64 system has its own memory bus, so time to access memory depends on whether the memory is directly connected to a given processor, or whether another processor needs to mediate, the definition of NUMA.

    --

    I've had this sig for three days.
    1. Re:And AMD... by addaon · · Score: 4, Insightful

      Transparently? Well, yes, from a programmatic point of view. Your old code will run fine. But not optimally. It would take different memory allocation algorithms to get optimum performance on a Hammer box. Hopefully, this will hape with that.

      --

      I've had this sig for three days.
    2. Re:And AMD... by BeBoxer · · Score: 1

      I've been told that it'll be about a 20% hit to access the memory on the wrong processor. I haven't actually seen any benchmarks or anything, but that's what a guy in the AMD booth at Supercomputing '02 said.

  5. ram question then by zogger · · Score: 1

    --OK, got a noob ram question then. Does this NUMA allow for upgrading total RAM beyond the original specs? Any sort of add-ons? I ask this from noticing it's used because of the physical distances it can access (among others).

    thanks in advance to yon knowledgeable ones

    1. Re:ram question then by u38cg · · Score: 1

      I don't think so. What you're asking is (for example) can you now plug a 512 meg module into a 256 meg limited mobo, yep? The answer is no, as this limit is defined by the mobo, though it may be hackable in other ways - but that would be even more OT. Numa is about accessing large sets of parallel memory banks, as others will expound at length elsewhere in the discussion. Essentially, it's of no practical use for playing Tux Racer, so it's OK to ignore it.

      --
      [FUCK BETA]
    2. Re:ram question then by jericho4.0 · · Score: 2, Interesting
      If the NUMA patch can handle latencies on the order of a few milliseconds, you might be able to use this to safely fool your kernel into thinking you have 120 gigs of RAM (from storage).

      Of course, actually doing this would involve jumping through a few hoops, and I have to think hard to come up with situations why this would be the way to go.

      Gees, any MB I've bought in the last several years can take more RAM than I'm willing to buy for it. I wonder what kind of memory limits the OP was asking about.

      --
      "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
    3. Re:ram question then by larien · · Score: 3, Informative
      Er, why use a hard drive as RAM when you can just add loads of swap space? The VM will handle that space more efficiently if it knows it's hard disk rather than RAM.

      However, the main way you might be able to add RAM over and above the MB limit is via some kind of PCI card with DIMMS on it. I'm not sure how that would work over PCI (even 66MHz/64bit) or how it would work at a lower level, but it might get by some limits. The limits OP was asking about may be of the order of trying to get over 1GB of RAM for some simulation code. Of course if you need over 1GB of RAM, buy a system which supports it.

      In any event, from what people are saying, the NUMA patch is a change to the scheduler, to ensure that processes run on the CPU nearest the RAM bank storing the data. I don't think it addresses trying to add RAM from other sources (either disk or hypothetical PCI card)

    4. Re:ram question then by juanillodgn · · Score: 2, Insightful
      Oh, my god!!! You've just reinvented EMS in 32-bit systems


      Remember those good ol' days?

    5. Re:ram question then by zogger · · Score: 1

      --that was my original idea further up. Perhaps not via a pci card, but maybe over ethernet, not only additional ram, but ram that could be shared, like this NUMA allows for the various cpu's on the same board, but with cpus in different machines. distributed & expandable RAM.

    6. Re:ram question then by oxfletch · · Score: 1

      No. You're still limited by the 36 bit PAE addressing scheme on intial ia-32 processors, as all memory is universally adressable, albeit at different speeds.

      We do end up with lots of PCI buses, etc. With careful programming, this gives you a shitload of IO bandwidth.

      Martin J. Bligh.

    7. Re:ram question then by owlstead · · Score: 1

      What do you mean, a 'little' slower? A 'normal' 32 bit 33 MHz PCI bus is very slow. A 1000 MBit network card already manages to fill that bus completely. The maximum PCI speed (64 bit / 66 MHz) is 4 times that. Still, only the speed of 3 gigabit network cards :(.

      Still it would be way faster than a hard disk drive. And it would off-load quite a lot of hdd activity needed for handling the swap file. Not to mention seek times. Obviously you wouldn't want to address the memory directly - even a big cache wouldn't hide the awfull performance.

      Memory is cheap and you would not need fast memory. You could also use it for disk cache, though that might really saturate the PCI bus (2 transfers minimum!!!).

      All in all, I would welcome such a PCI card. Obviously the 32 / 33 PCI bus is walking on it's last legs though.

      Maarten
    8. Re:ram question then by whereiswaldo · · Score: 1

      500 days of uptime... nice. Mind if I ask what OS, and what purpose do the servers serve?

    9. Re:ram question then by whereiswaldo · · Score: 1

      Interesting. As to the memory issue, are you using mysql_unbuffered_query rather than mysql_query?

      In order to achieve moving to the prior record, all records must be buffered. I'd almost bet this is the cause of your memory usage. Try using a unidirectional cursor instead which doesn't buffer the resultset and you should notice your memory stay low and performance go way up.

      If that's not possible, can you possibly add to your where clause so you can select 10% of the results at a time and re-execute the query 10 times to get at the different sections? (eg. by pkey range).

      If you've tried all of the above, there must be a memory leak somewhere. But I don't know your system, so take it with a grain of salt. :)

      I have to say I'm amazed that a machine swapping all day long every day can have a very long uptime!

  6. NUMA by Anonymous Coward · · Score: 5, Informative
    NUMA
    Short for Non-Uniform Memory Access, a type of parallel processing architecture in which each processor has its own local memory but can also access memory owned by other processors. It's called non-uniform because the memory access times are faster when a processor accesses its own memory than when it borrows memory from another processor.

    NUMA computers offer the scalability of MPP and the programming ease of SMP.
    1. Re:NUMA by TGK · · Score: 1

      Clearly the naming scheme was aranged for that acronym by a Clive Cussler fan.

      --
      Killfile(TGK)
      No trees were killed in the creation of this post. However, many electrons were inconvenienced.
  7. What about the feature freeze? by Screaming+Lunatic · · Score: 3, Informative
    I thought there was a feature freeze. There must have been some NUMA code in kernel already and this cleans up all the loose ends.

    Someone correct me if I'm wrong.

    1. Re:What about the feature freeze? by greppling · · Score: 5, Informative
      The NUMA-aware scheduler was merged recently despite the feauture freeze. The patch was considered non-intrusive (and safe for non-NUMA architectures). Feature freeze is not code freeze.

      See the good discussion in the LWN article on this topic.

    2. Re:What about the feature freeze? by jvj1 · · Score: 1

      The article also says that "The NUMA software is being worked on and refined in version 2.5, the testing ground for 2.6."

  8. NUMA? by Are+We+Afraid · · Score: 2, Funny

    This article says the code was submitted by Martin Bligh, not Dirk Pitt.

    Clearly it's a typo. I'll have to e-mail Clive about this.
    --
    Rot-13 my address to e-mail me.
    "So I hurry back to little earth / For another life another birth"
  9. Not just for big iron by awptic · · Score: 4, Interesting

    Not only is this beneficial for large computers, but also on smaller SMP systems with hyperthreading. On CPU's with hyperthreading,
    it's often faster for a process to reside on the same CPU but not necessary the same 'virtual' CPU when accessing memory.
    And alot of 8way+ systems are NUMA whether or not they are advertised as such.

    1. Re:Not just for big iron by smallfries · · Score: 1

      But those virtual CPUs are on the same physical chip with the same cache state so how can their distance to memory be different?

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    2. Re:Not just for big iron by bdeclerc · · Score: 1

      That's just it. Imagine a two-way SMP system with Hyperthreading. That's four virtual CPU's, but two virtual CPU's have access to local Level1/Level2 Cache, while the two other virtual CPU's have access to their own local Level1/Level2 cache. Hence : NUMA...

      Of course, a single-CPU HT system has no need for this.

    3. Re:Not just for big iron by be-fan · · Score: 2, Interesting

      Actually, the previous 2.5 scheduler handled hyperthreading just fine. The real draw is that this new patch makes hyperthreading just a subset of NUMA, which makes things much cleaner.

      --
      A deep unwavering belief is a sure sign you're missing something...
    4. Re:Not just for big iron by Cyberdyne · · Score: 1
      But those virtual CPUs are on the same physical chip with the same cache state so how can their distance to memory be different?

      Not different from each other, different from the other virtual CPUs, on other chips.

      If you have two threads, both accessing the same chunk of memory, think about these two options:

      1. Put both threads on different virtual processors of the same chip. That block of memory gets cached once, and both threads get cache hits.

      2. You put each thread on a different physical chip. Now, that block of memory is being cached by both chips at once, which means lots more bus traffic for each modification (each chip needs to tell the other what just happened); meanwhile, both threads are 'fighting' for cache with threads from other programs.

      Clearly, the first is better (more efficient) from a memory point of view: more data cache hits, less traffic between CPUs as they invalidate each other's cache lines. Similarly, it's better for the I-cache (instruction cache): you only cache and execute a single set of instructions, because both threads will tend to use the same code.

    5. Re:Not just for big iron by Merlin42 · · Score: 2, Informative

      Actually the HT implementation in the P4/Xeon chips does not act as you suggest in 1. When doing HT the cache is cut in half and each virtual CPU gets a half cache ... which is probably the main reason HT can yeild inferior performance for some applications.

      There is a very good reason for doing it this way. The P4 cache uses VIRTUAL addresses so if each virtual cpu is executing in a different virtual address space(which is allowed) then you need a way to differentiate which cache lines belong to each virtual cpu since they might very well both reference lets say virtual address 0xDEADBEEF which translates into a different physical address (and hence different data). Intel engineers went with the simple solution of splitting the cache in two, instead of adding an extra tag to each cache line which would have created extra overhead/latency on every cache access.

      I apologize for overusing the word virtual ... but I really couldn't help it too much. It just seems to be an overused word in CS/EE.

      --
      Thoughts on tech, Software Engineering, and stuff
  10. Re:A lot of talk about NUMA by Twirlip+of+the+Mists · · Score: 3, Informative

    Oh, for cryin' out loud. Dude, there's this thing called Google. Try it out some time.

    That said, I'll give you a hint: non-uniform memory access. If you've got a computer that uses different banks of memory as a single physical address space, then that computer has a NUMA architecture.

    If you want to maintain cache coherency across a NUMA system, you have to employ some tricks. These tricks are sufficiently complex to warrant their own name: ccNUMA.

    --

    I write in my journal
  11. CLIVE CUSSLER IS GOING TO BE PISSED by Soporific · · Score: 1

    For a great adventure story, read some of Clive's books.

    ~S

  12. Dirk by barnaclebarnes · · Score: 1
    Cool, Disk Pitt (tm) will be using Linux.


    Oh wiat. You mean _that_ NUMA.

    /b

    --
    [Please type your sig here.]
    1. Re:Dirk by fenix+down · · Score: 1

      Wow. How many Dirk Pitt fanboys so far? /. has the most bizzare tastes.

      All I ever read was the one with Howard Hughes' secret moon base. I think I stopped after I realized Dirk was gonna try and fuck the rich old Jackie-O impersonator. Actually, no, it was after they got on the blimp the second time. I always say you can't have more than one blimp scene in a story. Did Indy go back to the Nazi blimp? Nooo. He moved on to exciting new vehicles. Dirk can't let go of the damn blimp. It's like Hamlet or something. Blimps are Dirk's tragic flaw. They'd probably have been his downfall if I'd finished the story, too. I'll bet he has dreams where the blimp talks to him, the poor bastard.

    2. Re:Dirk by otis+wildflower · · Score: 1

      My dad's a DP fan, but I think you'll probably find more Slippery Jim DiGriz fans here ;)

  13. Linux v. Windows by Soporific · · Score: 1

    As long as you get whatever the heck you need to get done on whatever O/S or platform, everything after that is fun and games.

    ~S

  14. Re:Linux lacks democracy by Anonymous+Hack · · Score: 1, Offtopic

    OpenBSD doesn't have a democracy. It has a benevolent (heh) dictatorship. This is a Good Thing to a certain extent, because it keeps a project on-track. It gives it some level of direction, as opposed to letting things bloat... and bloat... and bloat... You can't compare open source to countries, because it's a lot easier to fork source and make your own branch than it is to revolt and declare independence. That said, sometimes the dictator can be a stubborn little bitch, and there's not much anyone can do. But that's why Linux users have the Alan Cox branches, and OpenBSD users have MicroBSD and other "unofficial" patched versions. It's no big deal.

    --
    I got a sig so you would remember me.
  15. Re:Linux lacks democracy by AlecC · · Score: 4, Insightful

    You misunderstand the way Open Source works. Linux actually has perfect democracy - *anybody* can take charge. Anybody - even you - could fork the kernel any time you wanted to. Of course, until you show why your stream is better than the main stream, you'll be pretty lonely on your fork.

    The only reason that Linus is still the controlling authority on the Linux kernel is that he is doing it pretty well. And he isn't without advice from others - there are hundreds of people only too willing to favour him with their advice.

    Every functioning organisation needs a chief executive - someone who makes the final decision. Even when you have executive committees - and, informally, most Open Source projects do - someone still has to make the final decision, to jusdge what the consensus actually is.

    Anybody can "call an election" on an Open Source project any time, by proposing a fork. That is much closer to perfect democracy, it seems to me, than one where you only choosw the Chief Exec every few years.

    As it is, Linux is a roaring success with Linus in charge. It ain't broke. don't fix it.

    --
    Consciousness is an illusion caused by an excess of self consciousness.
  16. SGI's systems (was Re:32/64) by grey1 · · Score: 3, Informative

    the MIPS/Itanium systems the parent refers to are (I assume) the SGI Origin and Altix multiprocessor servers, both 64bit, the first MIPS/IRIX, the second Itanium/Linux:

    Origin

    Altix

    --
    "we demand rigidly defined areas of doubt and uncertainty!"
  17. One learns something new every day by Bemmu · · Score: 5, Funny

    Thank you for explaining who Linus Torvalds is.

  18. Re:Linux lacks democracy by Anonymous+Hack · · Score: 2, Interesting
    Of course, until you show why your stream is better than the main stream, you'll be pretty lonely on your fork.

    Unfortunately it's not JUST showing someone you're better, it's "marketing" too. That's pretty hard in the case of Linux, because you can't use the name "Linux" anywhere - it's trademarked by Linus. If i made some funkyass Linux fork and called it Finnix, it wouldn't get the press Linux would, and you'd effectively be ten years back in time, building up a name etc. With BSD it's a little easier, because "BSD" in and of itself isn't trademarked, though it's doubtful whether you'd be able to get away with calling your Soviet Russia fork "NyetBSD".

    That said, i pretty much agree. Linux has so much stuff in it right now as a kernel (in the sense of running on a zillion architectures with a zillion features) i'd say Linus is pretty much pleasing everyone in the end. Most Alan Cox stuff gets rolled in, most commercial stuff does too. It's all good.

    --
    I got a sig so you would remember me.
  19. Re:Linux lacks democracy by Lussarn · · Score: 2, Informative

    You do not have to run Linus stock kernel.

    Not two vendors ship the same kernel. So in the end it's up to the vendor you use to tweak your kernel. Redhats are heavily patched to suit (what they belive) is there users needs..

    I think thats a good system.

  20. Re:Accepted by? by snofla · · Score: 2, Insightful

    the decision of linus to not accept the NUMA patches right away was correct. we now have a patch that doesn't affect non-NUMA archs...

    --
    i don't like style guides
  21. You know Slashdot is going "mainstream" when ... by rlowe69 · · Score: 4, Funny

    Linus Torvalds, the original creator of the operating system and still its top authority.

    You know Slashdot is going "mainstream" when people have to explain who Linus is.

    --
    ----- rL
  22. Linux Torvalds by peterpi · · Score: 1

    Wow, that guy called Linux changed his name to be just like that computer thing!

  23. Re:Feature freeze: NO NEW FEATURES! by stor · · Score: 1

    Not trying to be a cheerleader but apparently Linus originally planned 2.5 as the "Numa Support" version. There were certain features that Linus wanted that he didn't actually merge into mainline until AFTER feature freeze. He just queued them for inclusion.

    Cheers
    Stor

    --
    "Yeah well there's a lot of stuff that should be, but isn't"
  24. SGI must have added NUMA support as well by Anonymous Coward · · Score: 2, Interesting
    Hi,

    SGI must have added NUMA support for their Itanium-based Altix-servers as well. On their web-page it says: "Enhanced Operating System for High-Productivity Computing" [aka Linux] with "High-performance NUMA support".

    Anyone ever seen a patch for this?

    - jarman

    1. Re:SGI must have added NUMA support as well by oxfletch · · Score: 1

      SGI's stuff is (I believe) supported by their own 2.4-based tree, and is pretty much unmergable back into mainline.

      This is about stuff that's designed to be non-invasive enough to go into the mainline kernel, less bells and whistles, but a longer term goal, designed to work on every architecture. We'll slowly add features to it as they come up, if they're well tested across multiple arches and make sense.

      Martin J. Bligh.

  25. Linus' Acceptance... by sd790 · · Score: 2, Informative

    ...can be found here.

  26. Re:Accepted by? by Some+Bitch · · Score: 1

    Not really. If Linus were to flip his lid and totally lose the plot we'd all be running AC kernels in short order.

  27. It's time to stop reading slashdot when... by nibelung · · Score: 4, Informative

    they are copying Linux related news from CNET.

  28. Re:Linux lacks democracy by gilesjuk · · Score: 5, Insightful

    You underestimate the intelligence of Linus, he initially refused the NUMA patch as it affected performance on non NUMA systems. So the author of the patch got some help with it and the patch now works without hindering non NUMA systems.

    Surely this is quality control at its finest? every project has its project manager. Everyone is free to write their own applications without Linus controlling them, he just looks after his project which happens to be the kernel. Without strict quality control the kernel would be a right old dogs dinner by now.

  29. OT: Is Linus' fame diminishing or what?!? by ivi · · Score: 1

    Gee, when you have to -remind- us of Linus' claim
    to fame, it seems a sign that the History of Linux
    must be fading from the modern /.er's mind...

    I really -doubt- that it has...

  30. Re:Accepted by? by Queuetue · · Score: 2, Insightful

    It's not a SPF - if you want to run a kernel without the NUMA, go right ahead. If you want to run a kernel with DRM support, go right ahead. It's opensource - that's the whole point.

    Linus decides what goes into his tree. You decide what goes into your tree. If you don't have the time or skill to build your own tree, pick someone you trust, and use thiers.

  31. Recent Patch Modification by LJPeixoto · · Score: 5, Informative

    "More recently, the NUMA scheduler patch has been reworked (by Martin Bligh, Erich Focht, Michael Hohnbaum, and others) around a simple observation: most of the NUMA problems can be solved by simply restricting the current scheduler's balancing code to processors within a single node. If the rebalancer - which moves processes across CPUs in order to keep them all busy - only balances inside a node, the worst processor imbalances will be addressed without moving processes into a foreign-node slow zone. A simple (three-line) patch which did nothing but add the within-node restriction yielded most of the benefits of the full NUMA scheduler; indeed, it performed better on some benchmarks. Real-world loads, however, will require a scheduler which can distribute processes evenly across nodes. Occasionally it is necessary, even, to move processes to a slower node; a lot of CPU time on a lightly-loaded node will give better performance than waiting in the run queue on a heavily-loaded node. So a bit of complexity had to be added back into the new scheduler to complete the job."

    Extracted from:
    http://lwn.net/Articles/20741/

  32. Re:You know Slashdot is going "mainstream" when .. by Surak · · Score: 1
    Linus Torvalds, the original creator of the operating system and still its top authority.


    You know Slashdot is going "mainstream" when people have to explain who Linus is.

    Or when they have to even use his last name. :)

    --
    My journal has hot /. gossip.
  33. where are the GNU folx? by tommck · · Score: 1
    Linus Torvalds, the original creator of the operating system

    I was waiting for someone to jump all over this...

    T

    --
    ---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
  34. Re:A lot of talk about NUMA by Puu · · Score: 1

    "Non-Uniform Memory Architecture/Access." Not sure what that implies, except that sometimes you need to have data that is "far away" in a different memory (CPU group) node and use it like it was local.

    Like being able to ignore the speed diffrerences (although they affect perormance).

  35. Re:You know Slashdot is going "mainstream" when .. by Andreas+Remar · · Score: 1
    You know Slashdot is going "mainstream" when people have to explain who Linus is.
    Or when they have to even use his last name. :)

    Or when they claim that Linus created the OS GNU/Linux.
    --
    We are everywhere.
  36. You're experiencing BRAIN FREEZE by Lethyos · · Score: 1

    Sort some snow? Eat ice cream too fast? At any rate, you've experienced BRAIN FREEZE.

    --
    Why bother.
  37. IBM Replacing AIX? by linuxislandsucks · · Score: 1

    IBM not replacing AIX with Linxu? Yea rigth we really believe that type of FUD...:)

    --
    Don't Tread on OpenSource
  38. In Other News by crawling_chaos · · Score: 2, Funny

    Richard Stallman has sent an angry e-mail demanding a name change to GNUMA.

    --
    You can only drink 30 or 40 glasses of beer a day, no matter how rich you are.
    -- Colonel Adolphus Busch
  39. Linux has history by NoWhereMan · · Score: 2, Insightful
    Unfortunately it's not JUST showing someone you're better, it's "marketing" too. That's pretty hard in the case of Linux, because you can't use the name "Linux" anywhere - it's trademarked by Linus.

    Sorry if this seems rude, but it sounds like someone crying 'sour grapes.' Do a little research and you can easily find news group discussions about the profiteer who wanted to charge people to use the name Linux. The parent post is correct about your opportunity to fork a better implementation. It's a good thing my moderation points elapsed. I would have been looking for a crybaby option ;-)

  40. Kernel, not OS [boring] by diamond0 · · Score: 1
    I know this bores everyone, but statements like
    Linus Torvalds, the original creator of the operating system and still its top authority
    are why RMS rants endlessly that the environment should be called "GNU/Linux" instead. Please get it right, and credit Linus for the Linux kernel (and a few utilities) only.
    --

    --
    There is no hatred more pure and true than that expressed by children.
  41. What about P4s? by wass · · Score: 1
    P4's at 3.06 GHz and higher sold in the last few months are supposed to support hyperthreading. Does anybody know, though, whether slower P4's also do? K just bought a 1.8 GHz P4, and I'd really like to know whether I can hyperthread on it. (running linux)

    On that note, does one also need a hyperthreading mobo? I've searched, but after reading several linux kernel archives that google pointed me to, I'm still not sure whether my lowly 1.8 GHz P4 can hyperthread.

    --

    make world, not war

    1. Re:What about P4s? by dreamchaser · · Score: 1

      Hyperthreading was apparantly included in the silicon for most if not all P4's, but is physically disabled on all but the Xeon and P4 3.06+ CPU's. There is no way to enable it on your 1.8.

  42. NUMA support was improved, not added by slavemowgli · · Score: 3, Informative

    Contrary to what is said in the post, NUMA support has been in Linux for quite a while already. The recent patches accepted by Linus merely add NUMA awareness to the scheduler, which, while certainly being a prerequisite for Linux being used on production NUMA boxen, is not at all required for NUMA support in general.

    --
    quidquid latine dictum sit altum videtur.
  43. Re:Linux lacks democracy by jvj1 · · Score: 1

    It will be interesting how the Linus to the "next Linus" transition occurs... May be some vote perhaps... or would Linus appoint the next sucessor? :)

  44. National Underwater and Marine Agency? by UnrefinedLayman · · Score: 1

    Since when were Dirk Pitt and Al Giordino kernel hackers? I thought they were marine engineers?

    1. Re:National Underwater and Marine Agency? by cr0sh · · Score: 1
      I bet they got Hiram and Max to work on it...

      ;)

      --
      Reason is the Path to God - Anon
  45. Sequent technology? by SeattleSluggo · · Score: 1

    I wonder if this isn't some of the technology they snarfed from Sequent? I worked there in the late '80s and they were one of the top Unix technology shops around (or at least we thought so of ourselves at the time).

    1. Re:Sequent technology? by James+Youngman · · Score: 1
      I wonder if this isn't some of the technology they snarfed from Sequent? I worked there in the late '80s and they were one of the top Unix technology shops around (or at least we thought so of ourselves at the time).

      That was probably true in the 80s. It hasn't been true for a while though, I think.

      I used a cluster of Sequent NUMA-Q machines running DYNIX 4.4.2 in 1999 (in fact, I still use them occasionally). I find DYNIX (at least, that version) to be the most annoying Unix implementation I've ever used. It's so antiquated!

      It also had annoying features like telnetd defaulting to stripping the 8th bit of the data stream (turning the UK sterling symbol into a #). Oh, yes, and there was a hard-coded limit on the number of lines "tail" would cope with.

      The support is good though (but I've only used the support since Sequent were bought by IBM).

  46. And how does this relate to SGI? by wfrp01 · · Score: 2, Interesting

    SGI has also integrated NUMA technology into the linux kernel to support their new Altix servers. How do these two efforts relate? Is SGI's code generic enough that it could also be considered for inclusion in the mainstream kernel? Or is it specific to SGI's NUMA architecture? Is IBM's code generic enough that it would work on an Altix? What functional characteristics distinguish the two?

    --

    --Lawrence Lessig for Congress!
  47. Just what I've been looking for... by pmz · · Score: 1

    ...now I can put Linux on that 256-node NUMA cluster sitting in my spare bedroom...

    Seriously, though, this is one of the strengths of the GPL and is proof that the Linux kernel can only advance in time as it sucks up more and more features that will never go away (I hope 'refactoring' is in the developers' vocabularies!).

    --
    Healthcare article at Kuro5hin
  48. Re:Linux Community Can't Hack It by DarkMan · · Score: 2, Insightful
    ... the Linux
    community just can't hack it and make it
    without feeding off of the proprietary
    companies that it so despises.


    Proproetary companies are not despised. Most proprietary software is. Hardware companies that refuse to release driver level documentation are. Companies are not (unless everything that they do falls into the above catagories).

    Thus: Proprietry hardware companies that give open documentation are not 'despised'. Companies that write GPL code are not 'despised'. They are valuable members of the linux comunity.


    If your development model and community are so wonderful why do you accept handouts from proprietary companies?


    Because if it's GPL, and good, it gets in. It's not any more a handout than if you wrote some code, and submited it. There is nothing special about corporate ownership. If you have a problem with corporate submissions, you can modifiy the kernel, to remove their work. It's not a problem for me, or for the vast majority of the linux using comunity. I think that you seem to percive (or hold) an anti-corporate stance that is not representative of the comunity at large.
  49. Re:A lot of talk about NUMA by miu · · Score: 1
    You Americans are always so fucking obnoxious and think you are superior to everyone or anyone else. Get a life you fuck

    Whereas everyone in Asshatlandia is wise and good and would never be mean and bad like us bad and mean Americans.

    --

    [Set Cain on fire and steal his lute.]
  50. hmm by Cyno · · Score: 1

    I want to see this in a cluster. If the kernel can understand NUMA then it should be able to handle a cluster over a network, such as gigabit ethernet, IMO. Craylink is only what 800Mbps/full duplex? But, dammit Jim, I'm a Sys Admin, not a programmer.

    If it were possible to scale a cluster of PCs easily and keep a single concurrent system image there would be no limits to what we're capable of doing. Encode a video in 30 minutes or less, play the latest games with 2 year old hardware, etc.

    Make it so.

  51. Re:Feature freeze: NO NEW FEATURES! by oxfletch · · Score: 1

    For one, this was submitted before the feature freeze, which was the requirement that came down from Linus, not "merged by the feature freeze".
    It just got cleaned up since then.

    Secondly, the reason Linus accepted this was not that it came from IBM, it's that it was split up into small readable pieces, well documented, and obviously had no effect WHATSOEVER on standard machines.

    It's pathetic that you think Linus has so little personal integrity that he'd take bribes to put patches into the kernel. And who said this code was untested?

    Martin J. Bligh.