Wow, what a brilliant idea! Let's dump all this sissy research. After all, it may not deliver usable insights. Let's start a human breeding program instead! Who would have a problem with that? After all, it virtually guarantees to get us what we want!
As we all know, your dear friend Mr. Heinlein is alwasy to be taken by his word and always right.
What I've never understood is why a company as large as Microsoft never tried to create a second operating systems team with the goal of having it produce a new operating system from a clean slate?
While this sounds like a great idea, it's by no means a recipe for success. The words Plan9 and Itanium come to mind.
The number refers to the whole operating system. Not just a kernal as in Linux. The same team that works on the kernal works on the rest of the system as well.
I'm head of networking at the computer science department of a german university. Our network is largely based on fibre channel. Our distribution layer consists of about 1500 (no typo) fibre ports and is built of equipment from Foundry Networks exclusively (BigIrons). It is working great for years now.
As you can see, this is no small installation. While Cisco is an obvious choice for this kind of setting, it is not by far the only one.
When we built this system in early 2002 there were reasonable offerings from a number of other firms like Extreme Networks, Enterasys and Alcatel.
As strange as it may sound, an all-in-on shop like Cisco is especially great for small networks. If you build a big one, you must not commit yourself to any vendor too early. Preferably not at all. They'd charge you a fortune.
I do have one question, however; how is it that Internet Explorer is able to rewrite TCP rules? Doesn't it use win32's TCP service? Or does it call a different, special TCP service?
They can do anything they want in this regard. Most probably the windows networking team has made available special entry-points just for IE. Undocumented for the public, of course. IIS indeed has this kind of special system calls noone else really knows about.
I'm sure all this sounds pretty decent to M$, too.;)
hammer mp: consequences for kernel arch?
on
AMD Delays Hammer
·
· Score: 2, Interesting
Actually the part of the kernel which would be affected most by this kind of architecture is the memory management code. While allocating pages to processes you probably want to make sure most of a process' pages "belong" to the same CPU. If they don't, nothing you do to the scheduler will gain you anything. (See below why this is stupid.)
This isn't a particulary new requirement. You have to be careful about selecting pages for processes today even on single CPU systems to avoid cache thrashing. Because of the way first or second-level CPU-caches map to physical memory, certain memory-access pattern lead to constand reloading of the cache, making it pretty ineffective, even worse if it wasn't there in the first place. By carefully mapping physical pages to virtual memory the OS can avoid this problem. Solaris does this, I don't know about Linux. Probably.
So, this is one new requirement for the memory management code. No problem, we just make sure all process pages belong to one particular CPU and schedule this process to this CPU only. Everything is fast and nice. Intel is doomed. Or is it? Not so fast, all this is probably a bad idea:
We can't make sure pages on the right CPU a even available. What if they are not? Give out wrong pages? This would lead to results in running time which are not reproducable. This is really bad. It gets worse. What it the right CPU is not available because it's running some other process?
Probably it's best to allocate evenly distributed pages (some fast, some not so fast) to processes and not schedule them special in any way.
Slashdot Mirror
As we all know, your dear friend Mr. Heinlein is alwasy to be taken by his word and always right.
While this sounds like a great idea, it's by no means a recipe for success. The words Plan9 and Itanium come to mind.
Kernal? http://en.wikipedia.org/wiki/KERNAL
As you can see, this is no small installation. While Cisco is an obvious choice for this kind of setting, it is not by far the only one. When we built this system in early 2002 there were reasonable offerings from a number of other firms like Extreme Networks, Enterasys and Alcatel.
As strange as it may sound, an all-in-on shop like Cisco is especially great for small networks. If you build a big one, you must not commit yourself to any vendor too early. Preferably not at all. They'd charge you a fortune.
Check out John W. McKowns one-hand keyboard.
You'll get a bunch of solid information about this stuff and more by studying the Diceware FAQ. Highly recommended.
I'm sure all this sounds pretty decent to M$, too. ;)
This isn't a particulary new requirement. You have to be careful about selecting pages for processes today even on single CPU systems to avoid cache thrashing. Because of the way first or second-level CPU-caches map to physical memory, certain memory-access pattern lead to constand reloading of the cache, making it pretty ineffective, even worse if it wasn't there in the first place. By carefully mapping physical pages to virtual memory the OS can avoid this problem. Solaris does this, I don't know about Linux. Probably.
So, this is one new requirement for the memory management code. No problem, we just make sure all process pages belong to one particular CPU and schedule this process to this CPU only. Everything is fast and nice. Intel is doomed. Or is it? Not so fast, all this is probably a bad idea:
We can't make sure pages on the right CPU a even available. What if they are not? Give out wrong pages? This would lead to results in running time which are not reproducable. This is really bad. It gets worse. What it the right CPU is not available because it's running some other process?
Probably it's best to allocate evenly distributed pages (some fast, some not so fast) to processes and not schedule them special in any way.
Easy ;)