Re:Scheduler Enhancements for Apache
on
Linux 2.2.8
·
· Score: 1
Also they added wak_up_on_one, which affects accept (waking up only a process that is waiting, not all. *think to 250 apache process:)*
The funny thing is this probably won't affect the benchmarks at all. In the benchmarks, the web clients are all on fast LAN links, so they will quickly download the files and get on with the next request. In the real world your clients are on the other side of modems, ISDN connections and other bottlenecks like the Altantic and it takes them an appreciable time to get the data. So for a given bandwidth you have a lot more open connections ie a lot more Apache threads/processes. to get the data.
I wonder when there will be an Apache release that actually takes advantage of this.
On Linux it's no worse (for system stability) than killing any other sort of process. In fact under Linux a thread is very like a process, except that context switching is faster because the threads share the same virtual memory map.
Therefore (IIRC) it is impossible to kill a thread from another process
That may be, but at some point the overhead of starting a new process for every request will kill you anyway. Under Apache you can use PHP or mod_perl. With these there is no need to fork or compile a complete perl program for every request.
How small is the NetBench test data?
on
NOS Crossroads
·
· Score: 1
You'll find this interesting quote : "To isolate the disk subsystem as a bottleneck, we created a temporary RAM disk to hold workload files, effectively eliminating the need to hit the RAID array for data.
An interesting quote in itself. Is the NetBench data really so small you can hold it in RAM on a 2Gbyte workstation? Seems very unrealistic.
Last year AMD had sale of something like 2.5 billion dollars. Last _quarter_, Motorola had sales of 7.2 billion. And Intel? 7.1 billion last quarter.
Precisely. AMD is too small to be taking on Intel. Motorola could take the K7 design and run with it.
The rumour mill has Compaq buying AMD. I think they need to be bought by someone who knows how to run a fab and who won't be in competition with AMD's customers.
x86 is a dying technology
Merced is rumoured to be a flop, McKinley is rumoured to be late, Alpha is still not taking off. Sure x86 is dying, but it has been for years and that hasn't stopped Intel making a fortune on it. Remember, Windows 2000 is either going to be W98/DOS-based or late or both, so where does that leave non-x86 designs for the mainstream? Some years off.
The PowerPC 750 is a damn fine chip.
I'm sure it is, and Motorola should keep building it, but its not where the volume is, and that's not going to change. And while they are doing OK, they don't have any sort of performance lead over the `dying' x86 chips: According to The CPU Info Centre they get maximally 17.6 SPECint95s at 400MHz in Motorola's 0.22um process, while Intel is well into the twenties at 0.25um (I think).
When people suggest altering Linux to be able to handle more than 2GB RAM or files larger than 4Gb, the standard response from the developers is, if you want 64 bit get a 64 processor. Nice to see Oracle have got the message.
This looks like a reaction to the recent/current thread about what SGI are going to do when Merced is late and a disappointment. The Register picked up on it, and transferred it to the halfway mainstream online press, and they needed to do something to restore confidence.
Also the Linux bit is a reaction to all their dyed-in-the-wool Unix fans who liked the new machines, but hate NT.
The processor ID doesn't really add much that cookies didn't already give you. If you care about privacy you need control of your software. And we all know that Open Source is the best way to do that.
The latest motherboards for Alpha 21264/AMD K7 get some really good benchmarks for Streams (see the entry for the Compaq AlphaServer DS20, after the Crays), which measure the system's ability to shift a lot of data fast.
This is apparently the same motherboard that Microway is selling with its 6-way crossbar between the dual processor/RAM/PCI busses. The question is, with AMD set to beat Intel in absolute performance, and with high-end Alpha motherboards taking the K7, should SGI be basing their IA32 offerings on this bus instead of the P-II bus?
Apparently they want to make IRIX pure-64bit so they don't want to port it to IA32. Linux lets them deliver a good Unix anyway.
Now how about Veritas as a binary-only module? If it's as good as it's reputation it should be worth having. Of course, SCT's new journalled ext2 will narrow the gap by removing the need for a conventional fsck.
Take a look at the comments in/usr/src/linux/drivers/char/random.c. We already have a properly nondeterministic random number generator in the Linux kernel, so we don't need this new feature.
Slashdot Mirror
The funny thing is this probably won't affect the benchmarks at all. In the benchmarks, the web clients are all on fast LAN links, so they will quickly download the files and get on with the next request. In the real world your clients are on the other side of modems, ISDN connections and other bottlenecks like the Altantic and it takes them an appreciable time to get the data. So for a given bandwidth you have a lot more open connections ie a lot more Apache threads/processes. to get the data.
I wonder when there will be an Apache release that actually takes advantage of this.
On Linux it's no worse (for system stability) than killing any other sort of process. In fact under Linux a thread is very like a process, except that context switching is faster because the threads share the same virtual memory map.
Therefore (IIRC) it is impossible to kill a thread from another process
Not true for Linux
That may be, but at some point the overhead of starting a new process for every request will kill you anyway. Under Apache you can use PHP or mod_perl. With these there is no need to fork or compile a complete perl program for every request.
An interesting quote in itself. Is the NetBench data really so small you can hold it in RAM on a 2Gbyte workstation? Seems very unrealistic.
I couldn't see these lab notes anywhere. Could you post a URL?
See http://www.powerleap.com/pdg5/_di sc1/00000067.htm, http://www.powerleap.com/pdg5/_di sc1/000002a1.htm and http://www.powerleap.com/pdg5/_di sc1/00000341.htm. This would make a nice cheap and simple way for me to upgrade my Dual PPro-180 :-)
To get its hand on a good x86 design
Last year AMD had sale of something like 2.5 billion dollars. Last _quarter_, Motorola had sales of 7.2 billion. And Intel? 7.1 billion last quarter.
Precisely. AMD is too small to be taking on Intel. Motorola could take the K7 design and run with it.
The rumour mill has Compaq buying AMD. I think they need to be bought by someone who knows how to run a fab and who won't be in competition with AMD's customers.
x86 is a dying technology
Merced is rumoured to be a flop, McKinley is rumoured to be late, Alpha is still not taking off. Sure x86 is dying, but it has been for years and that hasn't stopped Intel making a fortune on it. Remember, Windows 2000 is either going to be W98/DOS-based or late or both, so where does that leave non-x86 designs for the mainstream? Some years off.
The PowerPC 750 is a damn fine chip.
I'm sure it is, and Motorola should keep building it, but its not where the volume is, and that's not going to change. And while they are doing OK, they don't have any sort of performance lead over the `dying' x86 chips: According to The CPU Info Centre they get maximally 17.6 SPECint95s at 400MHz in Motorola's 0.22um process, while Intel is well into the twenties at 0.25um (I think).
When people suggest altering Linux to be able to handle more than 2GB RAM or files larger than 4Gb, the standard response from the developers is, if you want 64 bit get a 64 processor. Nice to see Oracle have got the message.
OK. That is an even better reason not to want to port to a 32-bit target (IA-32) now.
As for Veritas, SGI is much more excited about its own log-structured file system, XFS, and rightly so, IMHO
Oops, that's what I meant of course
Also the Linux bit is a reaction to all their dyed-in-the-wool Unix fans who liked the new machines, but hate NT.
The processor ID doesn't really add much that cookies didn't already give you. If you care about privacy you need control of your software. And we all know that Open Source is the best way to do that.
This is apparently the same motherboard that Microway is selling with its 6-way crossbar between the dual processor/RAM/PCI busses. The question is, with AMD set to beat Intel in absolute performance, and with high-end Alpha motherboards taking the K7, should SGI be basing their IA32 offerings on this bus instead of the P-II bus?
Now how about Veritas as a binary-only module? If it's as good as it's reputation it should be worth having. Of course, SCT's new journalled ext2 will narrow the gap by removing the need for a conventional fsck.
Take a look at the comments in /usr/src/linux/drivers/char/random.c. We already have a properly nondeterministic random number generator in the Linux kernel, so we don't need this new feature.