Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn Wheeler <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Sun, 23 Jun 2024 17:46:11 -1000
Organization: Wheeler&Wheeler
Lines: 41
Message-ID: <87le2vatq4.fsf@localhost>
References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com>
	<v51tcr$26io$1@gal.iecc.com> <87plsb87hn.fsf@localhost>
	<v5aggt$j1nj$7@dont-email.me> <v5an0l$10bj$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 24 Jun 2024 05:46:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="85ab39e01912d81f9218aecd7c78d6be";
	logging-data="804546"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oTrGc3q6Za/Cgk/LQi/XJq9vmqeND/M4="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:tq8UP1JpCHh+ry5pVQF1GE1JkFs=
	sha1:CdRs0N1GJRwBZKw36o4nHXubBuU=
Bytes: 3257


John Levine <johnl@taugh.com> writes:
> Not really. VS1 was basically MFT running in a single virtual address
> space. The early versions of VS2 were SVS, MVT running in a single
> virtual address space, and then MVS, where each job got its own
> address space. As Lynn has often explained, OS chewed up so much of
> the address space that they needed MVS to make enough room for
> programs to keep doing useful work.

.... also SVS single 16mbyte virtual address space (sort of like running
MVT in CP67 16mbyte virtual machine) to "protect" regions from each
other still used the 360 4bit storage protection key ...  so caped at 15
concurrent regions ... but systems were getting faster, much faster than
disks were getting faster ... so needed increasing numbers of
concurrently executing regions ... so went to MVS ... gave each region
its own virtual address space (to keep them isolated/protected from each
other). But MVS was becoming increasingly bloated both in real storage
and amount it took in each region's virtual address space .... so needed
more than 16mbyte real storage as well as more than 16mbyte virtual
storage.

trivia: I was pontificating in the 70s about mismatch between increase
in system throughput (memory & CPU) and increase in disk throughput. In
early 80s wrote a tome that the relative system throughput of disk had
declined by an order of magnitude since 360 was announced in the 60s
(systems increase 40-50 times, disks increased 3-5 times). A disk
division executive took exception and assigned the division performance
group to refute my claims. After a couple of weeks, they basically came
back and said that I had slightly understated the problem.

They then respun the analysis for a (mainframe user group) SHARE
presentation for how to configure disks for increased system throughput
(16Aug1984, SHARE 63, B874).

more recently there have been some references that cache-miss, memory
access latency, when measured in count of processor cycles, is
compareable to 60s disk access latency, when measure in count of 60s
processor cycles (memory is new disk).

-- 
virtualization experience starting Jan1968, online at home since Mar1970