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."

143 comments

  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 Anonymous Coward · · Score: 0

      Yes this is old news. The NUMA patch has been accepted two weeks ago. See http://kerneltrap.org/node.php?id=562 for more.

      The good side is that it could have been a

    2. 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.

    3. 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)

    4. 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. first post by Anonymous Coward · · Score: -1, Offtopic

    first post, doubt it

    1. Re:first post by Anonymous Coward · · Score: -1

      You suck.

  3. 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.

  4. 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 Anonymous Coward · · Score: 0

      I hate to break this to you but this is not "one of the last remaining gaps between Linux and Solaris". Take it from somebody who develops on and uses both of these operating systems daily: Solaris is very far ahead technologically. Linux still has a significant way to go to catch up.

    2. Re:Imagine a beowulf... by Anonymous Coward · · Score: 0

      Seriously, this is something that will close one of the last remaining gaps between Linux and Solaris.
      Really? How's that? What makes you think that this would let Linux run on big SPARC boxes?

    3. 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.
    4. 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
    5. 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.

  5. 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 Anonymous Coward · · Score: 0


      Nope... Hammer is NUMA-ish, but does it transparently.

    2. 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.
    3. Re:And AMD... by MisterFancypants · · Score: -1, Troll

      Shut up, asshole. You have no idea what you're talking about.

    4. 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.

  6. A lot of talk about NUMA by Anonymous Coward · · Score: 0

    There's been a lot of talk about NUMA on Slashdot every now and then. I don't fear to say that I believe the majority of Slashdot readers don't have a clue about NUMA. ..And that's me included. What exactly is NUMA? Could somebody step forward and explain it clearly. Please.

    My humble guess is: NUMeric Arithmetic.

    1. 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
    2. Re:A lot of talk about NUMA by Anonymous Coward · · Score: -1, Troll

      Niggers Up My Ass.

      It's a HOWTO for surviving in prison.

    3. Re:A lot of talk about NUMA by Anonymous Coward · · Score: -1, Offtopic

      You Americans are always so fucking obnoxious and think you are superior to everyone or anyone else. Get a life you fuck

    4. 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).

    5. 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.]
  7. Sad News you might have heard by Anonymous Coward · · Score: -1, Troll

    I just heard this on the radio today..

    Popular OS Linux was found dead at the age of 15 on computers of internet dweebs worldwide. Prelimary autopsy reports indicate that the cause of death was massive irrelevence and inferiority of the source code. Truly a great loss to the world of insignificant software...

    1. Re:Sad News you might have heard by Anonymous Coward · · Score: -1, Redundant

      1. Slashdot gets a new twist on an old troll 2. ??? 3. Profit!

  8. 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 Anonymous Coward · · Score: 0

      > add RAM over and above the MB limit is via some kind of PCI card

      I would pay good money for that! On all of our servers, we've maxed-out the amount of RAM they'll take. The IBM servers we have are limited to only 512 Mbytes and the Sony Vaios to 64 Mbytes (damn Sony should be shot for adding that limit). We've got four dozen of them, and they're all rock solid, so I hate to spend more to replace them. On 22(?) of our servers, we have over 500 days of up time. The idea of taking a risk to buy a new server isn't very pleasant. I'm very comfortable with the reliability of what we have now. Being able to add a few hundred more megabytes, even if it was a little slower, would be great.z

    6. Re:ram question then by Anonymous Coward · · Score: 0

      EMS: oh the horror! This is nothing like EMS. EMS used a 64K "window" under 1096MB to map to a 64K segment in high memory. If you wanted to access memory that wasn't in the same window as the previous access, you had to first change the window. That's why it was so slow. Linux intelligently using a block of slow(er) memory to move less often used blocks into, would be a good thing.

    7. 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.

    8. 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.

    9. 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
    10. 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?

    11. Re:ram question then by Anonymous Coward · · Score: 0

      Most are running RedHat 6.0 with a few that run 6.2. Most have kernel version 2.2.16-3 from RedHat. The IBM servers are PC Server 325's with Pentium Pro 200's. The Sony Viao's are Pentium II 200Mhz (with the damn 64Mbyte limit on RAM). There is no IDE hardware in any of the IBM servers. There isn't even an IDE controller. Most of the IBM's have Mylex AccelaRAID (sp? cheaper version of the DAC960) SCSI controllers with three IBM 4 Gbyte drives. The ones that don't have that have TekRam (sp? cheap sym53c8xx SCSI card). Most are running MySQL and PHP3 with loads during the workday of over 5.0! Some of our huge PHP scripts consume over 500 Mbytes of RAM, so many of the machines swap continuously during the day. We had to convert from PERL to PHP, because the PERL scripts used even more RAM! I never was able to track down the problem, but when you do a database query in the middle of a loop (that runs 500,000 times, once for each customer), both PHP and PERL use a ton of RAM. More RAM would help greatly. The CPU's are fast enough for what we need to do. It's amazing they've run for that long at that load. The rest basically idle while running Samba and lpd. In over four years, we haven't had a power outage for over 2 minutes! That's the advantage of being downtown and having underground service.

      Also, we've got four dozen Sun IPC's, that as far as I know, have never locked-up. If I had to guess, I think they're over 12 years-old. They've been moved several times over the years, so they haven't had a chance to accumulate more than about a year of continuous uptime. They have Maxtor 200 Mbyte SCSI harddrives, 12 Mbytes of RAM, and 25 Mhz processors. They're running RedHat 4.2 with kernel 2.0.33 from RedHat. A default install of that version of RedHat only takes about 55 Mbytes of harddrive space, so we still have enough room to work with. They are rock-solid. We use them to terminate VPN connections to our customers. They run SSH. While the initial connection is slow (about 30 seconds!), they're fine after that. These servers (with RedHat 4.2!) have 10. addresses and can't get to the Internet. We put an identical machine with a modem at the customer's site. They dial-up to a Livingston PortMaster. I love these machines, because they're small, reliable, cheap, and don't end-up stolen like a PC might.

    12. 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!

    13. Re:ram question then by Anonymous Coward · · Score: 0

      I didn't mean to imply that all of it was inefficiencies in the scripting languages. Some of the data we work with is simply that big. The managers never want easy to write reports.

      As to the loops, PHP doesn't leak that much memory, but when you do something 500,000 times, it adds-up! We found that we could do the job in C with only 1/4 of the memory, but since we have one C programmer (me) and 14 PHP programmers, we just deal with the slow-down. Then we look for more IBM PC Server 325's on ebay.

      We do have to use mysql_free_result() in our larger loops to get PHP to free the memory used by result sets (data returned from a query).

      > Try using a unidirectional cursor

      I could be wrong, but I don't think MySQL has cursors of any type. Besides, with the way I've seen most PHP software written, you need to use buffered queries because you use the number of results in the return set for loop control variables. Also, we often display the number of rows at the top of reports or in deciding how to format a report, so that wouldn't help. Using unbuffered queries, that information isn't available until you work through the result set by hand.

      > select 10% of the results at a time

      Again, we make decisions based upon the size data before we display, so I don't think there's any way for us to use that. MySQL includes the very nice LIMIT clause that would help, but not for what we're doing.

      If MySQL had subselects, that would help us some. I'm often amazed at how fast MySQL is, so we try to do as much of the work with it as we can. Subselects would let us get rid of some of our loops and extra queries. We do use temp tables, but they're not as fast I expect they would be.

      > amazed that a machine swapping all day long

      Same here. It looks like an eventual error reading from a harddrive would cause the kernel to panic.

      Of course as soon as I brag about our reliability, we have a problem. I'm leaving now to go to the office on a Saturday night to look at a machine.

  9. 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 Ziviyr · · Score: 0, Troll

      Could NUMA be perverted into a VM mechanism? :-)

      --

      Someone set us up the bomb, so shine we are!
    2. 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.
  10. Why Bother? by Anonymous Coward · · Score: -1

    Linux is dead.

    1. Re:Why Bother? by Anonymous Coward · · Score: -1, Offtopic

      Linux is dead.

      Nothing will stop Linux. Linux is dead when this planet has exploded into oblivion and that's not gonna happen in recent years.

    2. Re:Why Bother? by Anonymous Coward · · Score: -1, Troll

      No, YOY are a windows user that has the brains of a potato and failed spectacularly to install linux mandrake 9.0

    3. Re:Why Bother? by Anonymous Coward · · Score: -1, Troll

      Some of us actually like to do something useful with our computers. Like instead of compiling a new kernel just to get the new network card working, we like to play real games, use real office tools and when we install new hardware it works out of box.

  11. Oh Crap by Anonymous Coward · · Score: -1, Troll

    Oh crap, not again, "IBM, the saviour" gave us NUMA support. my ass. we'd have support anyway. someone would wrote it even if IBM never helped. and you know what? I'm sick of them. It's so fucking obvious what they are doing. They're trying to convince us how they love us.

    But to me, they only sound like 50 year old pederasts that try to seduce little kids.

  12. hmmmmm by sickboy_macosX · · Score: -1, Offtopic
    does NUMA have anything to do with NAMBLA??

    No just kidding, now if only i can find where i put those Quad XEON HP Netservers, I knew they were here somewhere....

    Seriously i would love to have a computer that had massive amounts of processing power and ram, and i would try this shit out.

    --
    --- /* In Soviet Russia, the Mac OS X kernel panics you! */
  13. 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."

  14. MOD PARENT UP!!! by Anonymous Coward · · Score: 0

    This is a clear explanation of NUMA.

  15. Cool! by Anonymous Coward · · Score: 0

    Dirk Pitt is going Linux! Does Clive Cussler know about this?

  16. IBM RULES, FUCK YOU! by Anonymous Coward · · Score: -1

    I WANK OVER IBM'S LINUX SITE

  17. 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"
  18. 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
  19. SGI by Anonymous Coward · · Score: 0

    Linux has NUMA support since it runs on the SGI ccNUMA architecture (look for Altix 3000). This is nothing really new now, though!

  20. Linux lacks democracy by Anonymous Coward · · Score: -1, Troll
    still its top authority

    First of all, this is not a troll even if I criticize Linux (although I'm sure some Linux fanboy will no doubt mod me down).

    I wonder why more people are not complaining about the autocratic nature of Linux development. To me it is unconceivable people can be content with one single man running the show with "top authority".

    Wouldn't a more democratic system like that used in developing *BSD suit better these times when the soviet communism has collapsed and the remaining undemocratic institutions (Taliban, Cuba soon, ...) are quickly eradicated and replaced by democratic ones?

    1. 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.
    2. 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.
    3. 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.
    4. 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.

    5. 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.

    6. 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? :)

    7. Re:Linux lacks democracy by Tailhook · · Score: 0, 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.

      We already have lots of "democratic" systems. They come from vendors like Microsoft and the voters are paying customers. The result is a mess of screwed up priorities and feature bloat.

      According the article, and my own knowledge of the NUMA debate on linux-kernel, Linus objected to the original implementation from IBM because it was too intrusive and caused performance degradation on non-NUMA systems. I, for one, was pleased to see this prevented. I will explain why.

      Had this been a commercial operating system the NUMA work would have been incorporated right over the heads of whatever moral equivalent of Linus existed among the engineers within the organization. This would happen because the marketdroids would insist the NUMA feature check box be filled. The bosses would buy the marketdroid line and overrule the engineers. This is how systems like Windows get to be how they are. This is your "democratic" system at work.

      Martin Bligh approached this from the perspective that his work was indemnified from critical review due to it's importance. This is typical when an engineer thinks he has the marketdroids on his side. He made unnecessary technical compromises in his implementation and expected it to be overlooked. When you believe you have the blessing of the powers-that-be you will try to get away with murder.

      Unfortunately for our Martin, the Linux kernel isn't controlled by sales people. It's controlled by a man who has earned his credibility over a decade of public scrutiny. He has the power to make objective decisions based on technical merit. Linus forced the issue and the engineer was forced to reconsider his approach. The proof that Linus was entirely correct is that when the engineer was forced to reconsider his approach, he not only achieved the desired result, but now appears quite proud that his new implementation compromises nothing.

      Linus makes lots of decisions about the work of others. Often, this results in someone's hard work being excluded. This happens so frequently that if the community at large believed he a motive other than technical excellence he would have run out of credibility with all of us long ago. He hasn't, and there is no sign he's about to.

      We see these calls for "democracy" of some sort whenever a controversy appears. Perhaps we wonder if they have any merit? I don't, because I understand the motivation and I don't like it. Raw talent is a rare thing. When we witness extraordinary talent at work without a full understanding of the reasons we are often mystified and unsettled. When our own desires and motivations are in conflict with those who possess such talent, we are frustrated. This leads us to couch our desire to confound this mysterious force by suggesting "obviously" superior methods, such as "democracy".

      I do not fear the talent of others. I lack the means to make reasoned decisions on these matters and, probably, so do you. The difference is that I accept this and rely on my faith in certain people to do the correct thing. Linus is right far more often that he is wrong. He has my faith. I, too, was annoyed to see the select NUMA audience denied the features they wanted in the mainstream kernel. Clearly this sort of thing impedes World Domination (tm). In the end, however, I took it on faith that Linus had the clues necessary to make the call.

      --
      Maw! Fire up the karma burner!
    8. Re:Linux lacks democracy by DDR+Palmer · · Score: 0

      I agree. Democracy is a nonsense anyway, it is a Jewish concept. The only way to get things done is a strict hierarchy. The Führer knew this and that is why national socialism exists in the hearts of brave men today. 88

      --
      David Duncan Ross Palmer, author of OverChat
  21. What about BSD? by Anonymous Coward · · Score: -1, Troll

    IBM should do all this work for BSD. Oh, wait.
    It already did. AIX is BSD-based. It's a shame all this effort is going into re-inventing the wheel. linux has really set back the state of computing by 10 years and 10 more to come.

    1. Re:What about BSD? by Anonymous Coward · · Score: -1, Flamebait

      Troll my ass... Mod this guy up because this
      is right on the money. Linux *has* set back
      computing because they *do* keep reinventing
      the wheel. Not only that but they keep giving
      us inferior solutions and just totally screwed
      stuff like '--' option arguments for crying
      out loud. Okay, there are a few open-source
      projects which have produced good stuff but
      for the most part the Linux community never
      really understood Unix.

      Kent

  22. Feature freeze: NO NEW FEATURES! by Anonymous Coward · · Score: 0
    The NUMA-aware scheduler was merged recently despite the feauture freeze.

    Ah... one must just admire the depth of professionalism in the Linux community. Linus only accepted the patch because HE liked it. It really doesn't matter if he liked the code or just the kickbacks he must be receiving from IBM.

    And of course feature freeze is not code freeze. How else would you fix the bugs in the code?!

    It does not, however, mean that you can bring in a patch of untested code and just lump it in with the rest of it. Only by resorting to really twisted logic could one argue that feature freeze actually allows you to introduce new features!

    For chrissake, feature freeze doesn't mean anything anymore if you still can bring in things like new scheduler.

    1. 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"
    2. 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.

  23. CLIVE CUSSLER IS GOING TO BE PISSED by Soporific · · Score: 1

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

    ~S

  24. 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 ;)

  25. More information by Anonymous Coward · · Score: -1, Offtopic

    More information can be found here

  26. more information by Anonymous Coward · · Score: -1, Offtopic

    more information can be found here

  27. 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

  28. IN INCONTINENT SOVIET RUSSIA by DrMrLordX · · Score: -1

    Sad News might have heard . . .

    erm, excuse me comrade, I'll be right back.

    *flushes toilet*

    okay, now where was I? Oh yes . . .

    Sad News might have heard YOU!

    Now pardon me while I get some clean underwear.

  29. Van Halen Dead by Anonymous Coward · · Score: -1, Offtopic

    I just heard some sad news on the AP Radio News Network - Eddie Van Halen, legendary guitarist of the rock band "Van Halen", has died at Mt. Siani Hospital in Los Angeles today. The cause was said to be a reoccurance of lung cancer. No other details have been released at this hour. He will surely be missed by all in the music world.

  30. 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!"
  31. One learns something new every day by Bemmu · · Score: 5, Funny

    Thank you for explaining who Linus Torvalds is.

  32. Accepted by? by Anonymous Coward · · Score: 0

    One thing that still really concerns me with Linux is things like this - should the fact the great man himself (and dont get me wrong - I have heaps of respect for the guy) determine what should or should not be "included" with the kernel?

    This thing sounds good (and to be honest I really dont understand the implications of it fully) but doesent this sound a bit like we have an imposed gateway to delivery (no pun intended)? Or single point of failure?

    1. 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
    2. Re:Accepted by? by Anonymous Coward · · Score: 0

      An example of why I have so musch respect for the guy.

      But still - aint this a single point of failure?

    3. 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.

    4. 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.

  33. Informative submission by biglig2 · · Score: -1, Redundant

    I'm glad soosterh explained who this Linus guy is, I've been wondering about that.

    --
    ~~~~~ BigLig2? You mean there's another one of me?
  34. GOATSEX! by Anonymous Coward · · Score: -1, Troll

    GOATSEX!

  35. 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
  36. Linux Torvalds by peterpi · · Score: 1

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

  37. 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 Anonymous Coward · · Score: 0

      SGI has already done this. IBM is late. The Altix supports NUMA and NUMA across multiple nodes with NUMAflex. Yet again, SGI get's the shit end of the stick....

      http://www.sgi.com/servers/altix/64bit_linux.htm l

    2. 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.

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

    ...can be found here.

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

    they are copying Linux related news from CNET.

    1. Re:It's time to stop reading slashdot when... by Anonymous Coward · · Score: 0

      Hypocrite

  40. 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...

  41. 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/

  42. linus torvaalds the CREATOR of the O.S. ? by asbesto · · Score: 0, Flamebait

    hey people, linus torvaalds created only the kernel. the entire O.S. is GNU/Linux, and his top authority it seem to be a guy called Richard Stallman asbesto http://www.freaknet.org

  43. 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.
  44. 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.
  45. 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.
  46. For Sequents? by Anonymous Coward · · Score: 0

    Could this mean that IBM will provide a distribution of Linux for their former Sequent boxes, and we can dump MP-RAS?

    1. Re:For Sequents? by Anonymous Coward · · Score: 0

      (slaps self in head)

      That's Dynix, not MP-RAS (grumble ... NCR ... grumble)

  47. 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.
  48. 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
  49. Linux Community Can't Hack It by Anonymous Coward · · Score: -1, Flamebait

    Once again we see evidence that the Linux
    community just can't hack it and make it
    without feeding off of the proprietary
    companies that it so despises. What
    hypocrisy. If your development model
    and community are so wonderful why do
    you accept handouts from proprietary
    companies? Why don't you put your money
    where your mouth is and take a community
    position that no contributions will be
    accepted from proprietary companies?

    Kent

    1. Re:Linux Community Can't Hack It by Anonymous Coward · · Score: 0

      Please take a refresher course in Troll 101. This is too weak. I'm ashamed...

    2. Re:Linux Community Can't Hack It by Anonymous Coward · · Score: 0

      > Please take a refresher course in Troll 101.
      > This is too weak. I'm ashamed

      Nice try but your reply really doesn't cut it.
      Try offering a counter argument and answering
      my question.

      Kent

    3. Re:Linux Community Can't Hack It by otis+wildflower · · Score: 0, Offtopic

      uhh, Linus wouldn't accept anything into the kernel that wasn't GPL'd.

      Ergo, you are an ass.

    4. Re:Linux Community Can't Hack It by Anonymous Coward · · Score: 0

      Your comment reflects your inability to
      address the issues. Hence you restort to
      mechanisms such as downgrading comments to
      suppress dissent. Ergo, you show the true
      spirit of the Linux community.

      Have a nice day...

      Kent

    5. 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.
  50. 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
  51. 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 ;-)

  52. Articles about linux by Anonymous Coward · · Score: 0

    I think it's becoming more obvious that articles (sorry, links to articles) about Linux aren't really crash hot news worth material.

  53. 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.
  54. Re:You know Slashdot is going "mainstream" when .. by Anonymous Coward · · Score: 0

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

    Actually, I saw that and just assumed that the submission was written by a journalist at CNet. The submission uses the same structure and idiom that journalists tend to use.

  55. 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.

  56. 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.
  57. 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
  58. 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).

  59. 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!
  60. 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
  61. 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.

  62. What? Numa? by Anonymous Coward · · Score: 0

    Clive Cussler? Dirk Pitt? Linux? What?

  63. Yes, we know about Linus by Anonymous Coward · · Score: 0

    Soosterh, when you copy text directly from an article, you're supposed to put it in quotes or but it in italics and set it apart from the rest of the text. Expaining who Linus is on /. is quite unnecessary and just sounds dumb.

  64. Naked UMA (Thurman) by Anonymous Coward · · Score: 0

    It stands for Naked UMA, so the linux kernel now has naked pictures of Uma Thurman.

  65. Bare metal by Anonymous Coward · · Score: 0

    "Linux could just run on big IBM boxes (bare metal)"

    Well, on big IBM boxes Linux run emulated whereas they actually do run on "bare metal" on weenies' x86 machines.

  66. Imagine an OpenMosix... by Anonymous Coward · · Score: 0

    Any word on whether OpenMoxis can utilise this functionality? Now *that* would be useful "for 99% of users out there". Need speed? Just plug in another $500 new box!

  67. Last Post! by alpg · · Score: 0

    The best executive is one who has sense enough to pick good people to do
    what he wants done, and self-restraint enough to keep from meddling with
    them while they do it.
    -- Theodore Roosevelt

    - this post brought to you by the Automated Last Post Generator...