upscope said the following on 03/20/2010 05:49 PM:
Actually goes back further than that. The old Xerox Sigma 9's and 8's ran multiple OS's, with while executing look ahead for commands. The memory and I/O processors were multi ported in the late 1960's.
I worked with a GE machine that was designed for real time control (signalling, machinery, for example rail-road switching) that had FIVE ported memory/backplane. The granularity of memory access was 512 bytes. So one of the memory IO channels could be locked to the disk DMA controller and another to the tape controller, and since they were autonomous data units that took command blocks from memory they didn't need CPU intervention once those blocks were set up. This multi-channel memory is one reason why those old machines were so fast. Not only was the IO "autonomous" (not requiring CPU intervention) but it did not block CPU access to memory. And yes we've returned there. In various ways. But there's a problem Granularity of current access is limited by how big the chips are (until you use chips that migrate this down to the chip level). Sadly things are not always as simple as they seem. SMP kernel code for '*just*' two processors is pretty simple; doing it or N processors without spin locks isn't. I takes some redesign, as we've seen over the years in Linux. The same applies with threading. On the big IBM machines, the Xerox and the GE machines, while the principles were the same, the details were different. For example, I once wrote a striping disk controller for a GE machine where FOUR hardware controllers (each with a different spindle) each took over a memory channel simultaneously and **BLURP** that 4K segment hit the disk(s) damn fast and then unlocked the channels. It was tied to that very specific hardware. I couldn't be generalized. But there are many limitations with Linux. Yes, we can have custom drivers, but so much *has* to be general. And that isn't always easy. -- The great successful men of the world have used their imagination ... think ahead and create their mental picture in all it details, filling in here, adding a little there, altering this a bit and that a bit, but steadily building - steadily building. -- Robert Collier -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org