Deutsch English Français Italiano |
<87ed8e7os5.fsf@localhost> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!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: Sat, 29 Jun 2024 23:39:22 -1000 Organization: Wheeler&Wheeler Lines: 49 Message-ID: <87ed8e7os5.fsf@localhost> References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com> <e4f7278a5ff4e0b488306ae43aac8135@www.novabbs.org> <v5nbfo$3hdrc$1@dont-email.me> <v5o6jr$37jie$1@dont-email.me> <v5pjcc$25j5$1@gal.iecc.com> <v5q6qm$5fhe$1@dont-email.me> <v5qn67$c1dr$1@dont-email.me> <v5r13f$dn62$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sun, 30 Jun 2024 11:39:24 +0200 (CEST) Injection-Info: dont-email.me; posting-host="a7d4b7a17d1bcfd540865bbd0b7e063f"; logging-data="498395"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19OOvFfjJkm8Z2kEd9aQX1cMjKcZ5j90FI=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:XudZiig5XT6GoRe9aEPdUb2Ytzs= sha1:LGFByhoMWpkxHMPP2A/68VJVlDA= Bytes: 4025 Lawrence D'Oliveiro <ldo@nz.invalid> writes: > Work out the numbers. The CPU time necessary to copy a single record is > most likely a small fraction of the time it takes to service an I/O > interrupt. > > And this is not taking into account the fact that I/O interrupts run at a > higher priority than user-level tasks like copying buffers, anyway. back to IBM decision to add virtual memory to every 370 ... aka MVT storage management was so bad that regions had to be specified four times larger than used ... as result a normal/typical 1mbyte 370/165 only ran four regions concurrently, insufficient to keep system busy and justified. adding virtual memory, could run MVT in a 16mbyte virtual address space (aka VS2/SVS, sort of like running MVT in cp67 16mbyte virtual machine)... increasing number of concurrent running regions by factor of four times (up to 15) ... with little or no paging. however, created different overhead (in part because the FS failure gave page-mapped filesystems a bad reputation) ... application filesystem channel programs were created (usually) by library routines in application space ... and the channel programs passed to EXCP/SVC0 for execution, now would have virtual addresses (rather than real required by I/O system) ... this required EXCP/SVC0 make a copy of every channel program, substituting real addresses for virtual addresses (initially done by crafting CP67's "CCWTRANS" into EXCP/SVC0). 370 systems getting larger then were then banging against the concurrent region 15 limit imposed by the 4bit storage protection scheme keeping regions separated and had to transition from VS2/SVS single address space to VS2/MVS where every region was isolated in its own separate address space. However, MVS was increasingly becoming quite bloated (also EXCP/SVC0 still had to make channel program copies) and device redrive (device idle between interrupt to starting next queued request) was a few thousand instructions. I had transferred to SJR and got to wander around datacenters in silicon valley including bldg14&15 (disk development and product test) across the street. They were doing prescheduled, 7x24, stand-alone testing and had mentioned they had recently tried MVS, but in that environment, MVS had 15min mean-time-between failure (besides its significant device idle waiting for device redrive) requiring manual re-ipl/reboot (aka test devices frequently violated all sort of rules & protocol). I offered to rewrite I/O supervisor to make it bullet proof and never fail allowing any amount of ondemand, concurrent testing .... improving productivity (as well as cutting to a couple hundred instructions between taking interrupt and redriving device). -- virtualization experience starting Jan1968, online at home since Mar1970