m...@mentor-services.com (Mike Myers) writes: > I'm quite familiar with that project. Three others and I actually > implemented a prototype which let a TSO user issue the command CMS > which would obtain a block of storage in the TSO address space and > load and run the CMS kernel using SIE. Attempts to perform file I/O > would interrupt SIE and execute code which implemented the CMS file > system and all needed file functions in a VSAM data set, using CI file > I/O. A later design would use the VSAM actual block processor, as > opposed to CI file I/O. That file system implementation was my > contribution to the project. > > Two of us were assigned as technical team leaders for the intended > product development. We were staffing our teams when the project was > killed.
re: http://www.garlic.com/~lynn/2012o.html#34 Regarding Time Sharing http://www.garlic.com/~lynn/2012o.html#37 Regarding Time Sharing ... and much more efficient mapping than VSAM ... os/360 did contiquous allocation ... as well as multi-block read and even concurrent multi-buffer overlapped asynchronous operation. cms, unix and various systems can trace back to CTSS either directly or indirectly. base cms did scatter allocation, contiguous only occuring accidentially. it would try and do 64kbyte executable load ... which would only result in real multi-block operation if it mapped to sequential contiguous. lots of page-mapped filesystem would do the memory mapping of virtual address space to portion of filesystem and then actual load only happening with serialized, synchronous page-faults ... single 4k at a tim (not multi-record operation, no asynchronous overlapped buffers, etc). when I first did cms page-mapped ... it raised the filesystem abstraction ... eliminating lots of the overhead involved in simulating channel program operations as overhead elimination when there was a one-to-one mapping between the filesystem operations and the virtual memory operations. the issue was not to fall prey to loading via pure page fault operation with the inefficiency of every page a serialized, synchronous, non-overlapped 4k transfers. unix filesystem has done this with lots of hints between the filesystem operation and the disk management ... with things like read-ahead, write-behind, and various other things ... to improve disk operating throughput and overlapped operation. Later unix & unix-like systems have also done contiguous allocation support. However, some downside was almost all disk i/o went through system buffers and required copying between system buffers and application buffers. POSIX aysnch I/O initially was targeted for large multi-threaded DBMS applications to do asynchronous I/O directly to/from application address space. so another part of the initial cp67/cms paged-mapped filesystem operation was be able to maximize multi-block asynchronous disk transfers (not loosing a lot of disk performance via synchronous serialized page faults) ... as well as adding the logic to explicitly do contiguous allocation. one of the fall-outs of page-mapped was it was able to leverage lots of other work I had done to the virtual memory system to optimize page i/o operations (like dynamically creating multi-record I/O chains optimized for optimial device transfer). the result then both significantly descreased the total filesystem cpu processing ... but for moderate I/O intensive applications improved the elapsed time throughput by a factor of three times. some old numbers comparing page-mapped and non-page-mapped CMS filesystem operation on 3330 disks http://www.garlic.com/2006.html#25 DCS as SWAP disk for z/Linux later on 3380, I could frequently get 3times the throughput of unmodified CMS filesystem. in the referenced comparisons, the non-paged-mapped are physical disk SIOs, independent of number of 4k block transfers, while the numbers for paged-mapped are the number of 4k block transfers (independent of the number of physical I/Os, lower elapsed time implies fewer physical I/Os with larger number of blocks transfered per I/O). the page-mapped interface also provided support for shared image function ... i.e. page-mapping supporting same physical image concurrent in multiple different virtual address spaces. this replaced the vm370 DMKSNT (SAVESYS) requiring privileged operation to define shareable images. I would claim that the issue of serialized, synchronization with page-fault oriented paged-mapped systems is similar to the serialized synchronization that the mainframe channel oriented FICON layer significantly reduced throughput compared to the underlying fibre-channel ... discussed in these recent posts: http://www.garlic.com/~lynn/2012o.html#25 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012o.html#27 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee as aside, one of my hobbies was providing production operating systems to internal datacenters. when the science center was still on cp67, the future system effort was in progress, and company moving to 370s (& vm370) customers started to drop off ... but then science center got 370 and I migrated a bunch of stuff from cp67 to vm370 (including the paged mapped filesystem stuff) ... the internal datacenter customers picked up again ... including places like the internal world-wide sales&marketing HONE sytems. some past posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone old email refs: http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
