Mailinglist Archive: opensuse (1523 mails)
| < Previous | Next > |
Re: [opensuse] systemload / cpu's
- From: Anton Aylward <anton.aylward@xxxxxxxxxx>
- Date: Sat, 20 Mar 2010 20:00:08 -0400
- Message-id: <4BA56188.50901@xxxxxxxxxx>
upscope said the following on 03/20/2010 05:49 PM:
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
| < Previous | Next > |