On 2012-07-09 03:01, Bob Armstrong wrote:
I don't know if you understand the concept of memory partitions in RSX
properly.
No, I guess not. The usefulness of partitions in an unmapped system is
easy to see - since tasks have to be linked (er, "TKBed") to run at a
specific virtual address and all tasks have to share the same address space
at the same time, you have to fit the tasks into memory. It's really the
address space that's being partitioned as much as it is the memory. The
concept is not unlike overlays.
Well, on an unmapped system, not only do you have to worry about the region, but you
actually have to task build your program for a specific address in that region, since you
don't have virtual memory.
Once you have an MMU, you (almost) stop worrying about the address offset parts of regions
in TKB, but you still have to say which partition it should request the memory in.
Of course, you can always override which region a program tries to run in when you install
it. The information specified in TKB is just the default values. Nothing force you to
actually use those values.
This is what the help in RSX says:
.help tkb opt par
PAR=par-name[:base:length]
PAR specifies the partition for which the task is built.
In a mapped system, you can install your task in any system partition
or user partition large enough to contain it. In an unmapped system,
your task is bound to physical memory. Therefore, you must install
your task in a partition starting at the same memory address as that
of the partition for which it was built.
But once you have an MMU the whole procedure is pointless. Every task and
every processor mode can have its own contiguous virtual address space.
Right. Except that contiguous virtual address space does not necessarily map to a
contiguous physical address space.
Nobody needs to share virtual address space with anybody else. And the
mapping to physical memory is (for practical purposes) completely arbitrary
and easily changed on the fly. What's gained by partitioning physical
memory into fixed chunks that are allocated only to specific uses and can't
be shared?
Tasks that share the same region compete for the memory resources. Tasks in separate
regions do not.
Also, sometimes tasks want to share parts of their memory space with others.
Also, memory partitions are not allocated to a specific user. Memory partitions are
managed by the system manager, and are normally set up at boot time (even if this can be
handled and modified at any point).
Actually I thought RSX worked the way you described for M+ -> everything
ran in a "GEN" partition, and the system just made as many GEN partitions as
it wanted. Only if you were unmapped did you care which partition something
ran in.
Um... No. There is only one GEN partition. There can only be one partion called GEN. The
name of a partition needs to be unique.
A memory partition is more like a meta object. When a task is run, it allocates region
within the partition. Many tasks can run in the GEN partition (for example), but they all
have their own regions. Otherwise they would all share the same memory.
And if more tasks try to allocate memory in a region than there is room for, they are
constantly swapped in and out by the scheduler, based on their swapping priority.
When you don't have the ability to lock regions in memory, you can constantly be
swapped out if some other process in the same partition requests more memory than there is
free in that region.
Good idea. But there are SCSI controllers for the Q-bus, as well as the
KDA50...
I have both of those, but I'm not going to waste 'em on a 11/23! :-)
:-)
Actually that's a pretty realistic attitude back in the day - these are
more expensive mass storage devices and anybody who could have afforded them
probably would have bought a faster CPU too.
I know of places who still ran 11/23+ machine in production at least until only a couple
of years ago. Moved from RQDX2 to SCSI about 6 years ago...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic
trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" -
B. Idol