IBM 610 workstation computer 3446
On Sun, 26 Feb 2006 13:37:25 +0000, jmfbahciv
Call L2's memory then. If an L2 contains dirty data it will respond in place of (or before) main memory. I knows main memory isn't consistent and will go through the gyrations needed to make it (at least look) so.
Oh, we make wires pretty small these days. ;-) You don't need to immediately touch every processor. Opterons each touch three, and those three, touch three more, and... At least up to eight processors (and two I-O hypertransport ports, IIRC) without a hardwae bridge. Thousands of processors has been done, but the market isn't so big. Thread Debt Management (i.e. software) is still the problem, as I see it.
Who said PCs were single-instruction end systems anymore? Mainframes and workstations have been doing these thigns for *years*. Cache protocols are quite well known art.
IBM 610 workstation computer 3450
ref: the problem was that with one cpu ... the cache ran at full-speed. with two cpus, the cache ran at full-speed ... but its...
a few times now. It pretty much works. ;-)
Timesharing isn't the end-all, but using your example, yes, when CPU1 takes over a task that CPU0 has just completed memory must be consistent. CPU0 could flush its caches before letting CPU1 take over, but that's time wasted. With coherent caches CPU1 snoops dirty data out of CPU0's caches. Of course it would be better if the OS left the thread on CPU0 (affinity) since it's caches are fresh.
...and then I'd be lost too. ;-)
I don't see any inconsistency here. The fact is that one cannot cache I-O since it will change when things outside the "system" change. I-O must also be ordered since actions on one bit may cause changes to others.
But what if the external world has chenged the state of the I-O device? The cached copy of that I-O device will still show the previous state.
Sure, why save code pages to VM when it's just as easy to refetch it from the original? I also throw away a *lot* of bits when I shut down my computer. ;-)
...and that's the way it has to be. A write to one I-O bit may change the state of others. A read may even change the state of the port. Order must be forced.
I-O control lists aren't caches in the same sense. It's a list of commands for an I-O device to execute.
30 years of existence says otherwise.
IBM 610 workstation computer 3448
Sigh! Who is the it in that sentence? This question is the most important section of this post. My observations of hardware types is that they never stop to answer this question with clarity...
Done all the time. We have architects responsible for such things.
IBM 610 workstation computer 3451
there was a separate issue-paper involving TSS-360 on 360-67 which claimed over three times the thruput on two-processor 360-67 compared to single...
With a new hardware generation coming about every two years, there have been many chances to get it right. It does work.
When hardware fails? That's another topic completely. What happens when the hardware can't add?
IBM 610 workstation computer 3447
Who is the I in this last sentence? I am stating that the I is the OS. It cannot be hardware. It is only the OS who knows which data is the "correct" to...
Nope. Everyone on the field can move, jsut not to the same spot at the same time. If someone tries, a whistle blows, and the zebras sort all it out.
It is, though I'm no expert on schedulers.