OK, I posted it at http://lse.sourceforge.net/numa/config.mem - this is just the standard config I use every day on this machine. If I wanted to be a real benchmark weenie, I could make this go much faster;-)
What I'm really interested in is what makes it go slow on a "normal" workload, so we can fix the scalability problems.
NUMA provides you with a single system image, so there's no need to rewrite your software. At the moment, we're working on default behaviours so that normal software works reasonably well. For something like a large database, we're providing APIs that will allow you to specify things about how processes interact with their memory and each other, allowing you to increase performance further.
The hardware looks a little like 4 x 4way SMP boxes, with a huge fat interconnect pipe slung down the back (10 - 20 Gbit/s IIRC). But there's all sorts of smart cache coherency / mem transparency hardware in there too, to make the whole machine look like a single normal machine.
Yes, I used stock GCC (redhat 6.2).
re Scalability, the largest machine you can build out of this stuff would be a 64 proc P3/900 with 64Gb of RAM. SGI can build larger machines, but I think they're ia64 based, which has it's own problems.
It's not that hard to set up, but not something you would build in your bedroom;-)
These machines were designed to run huge databases. The IO scalability isn't there in Linux yet as it was in Dynix/PTX, and there hasn't been so much work on the scalability of Linux as there has on PTX, but it'll get there pretty soon;-)
So yes, it will apply to other stuff, though maybe not as well as it could, quite yet.
Why on earth would you set up a new remote.
Buy / beg / borrow / steal someone else's,
and work out with the PC's IR receiver what
codes it's sending you. Use those. Universal
remotes are only $20 or so...
Slashdot Mirror
OK, I posted it at http://lse.sourceforge.net/numa/config.mem - this is just the standard config I use every day on this machine. If I wanted to be a real benchmark weenie, I could make this go much faster ;-)
What I'm really interested in is what makes it go slow on a "normal" workload, so we can fix the scalability problems.
It doesn't scale too well yet. A single quad (fairly standard SMP 4 way) will do the dirty deed in about 47s.
NUMA provides you with a single system image, so there's no need to rewrite your software. At the moment, we're working on default behaviours so that normal software works reasonably well. For something like a large database, we're providing APIs that will allow you to specify things about how processes interact with their memory and each other, allowing you to increase performance further.
;-)
The hardware looks a little like 4 x 4way SMP boxes, with a huge fat interconnect pipe slung down the back (10 - 20 Gbit/s IIRC). But there's all sorts of smart cache coherency / mem transparency hardware in there too, to make the whole machine look like a single normal machine.
Yes, I used stock GCC (redhat 6.2).
re Scalability, the largest machine you can build out of this stuff would be a 64 proc P3/900 with 64Gb of RAM. SGI can build larger machines, but I think they're ia64 based, which has it's own problems.
It's not that hard to set up, but not something you would build in your bedroom
These machines were designed to run huge databases. The IO scalability isn't there in Linux yet as it was in Dynix/PTX, and there hasn't been so much work on the scalability of Linux as there has on PTX, but it'll get there pretty soon ;-)
So yes, it will apply to other stuff, though maybe not as well as it could, quite yet.
What are the 5 things you most want to change in 2.4?
Why on earth would you set up a new remote. Buy / beg / borrow / steal someone else's, and work out with the PC's IR receiver what codes it's sending you. Use those. Universal remotes are only $20 or so ...