Multiple mappings
|
From: Anne & Lynn Wheeler on 11 Dec 2006 10:00 nmm1(a)cus.cam.ac.uk (Nick Maclaren) writes: > Let us exclude the matter of zero-initialised pages, and concentrate > on ordinary physical pages mapped to two different virtual addresses > in a SINGLE address space. My belief is that almost all systems > permit this, but it is an essentially unused facility, for very good > reasons, such as: even if the system doesn't get confused, the user > probably will! > > Does anyone know of a reasonable, real, application where it is done? > And. if so, what is it used for? re: http://www.garlic.com/~lynn/2006w.html#17 Cache, TLB and OS http://www.garlic.com/~lynn/2006w.html#10 Cache, TLB and OS nope ... my virtual memory management didn't preclude having the same shared segment at different virtual addresses whether in different virtual address spaces or the same virtual address space ... but i didn't remember ever coming across a use for having multiple mappings of the same shared segment within the same virtual address space. recent posts about porting virtual memory management from cp67 to vm370 http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks? this is recent post about an old hack for >16mbyte support in 370 http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte for 370 where i proposed temporarily stuffing a couple real page addresses into a virtual address space in order to copy from above the real "16mbyte" line to below the "16mbyte" line. in the scenario where it was purely copying a 4k virtual page ... it wasn't likely to have multiple copies. However for the scenario where data was being copied from a virtual page (above the line) into kernel working storage (below the line), and it was a multiprocessor configuration where more than one processor was attempting this; the process involved temporarily dynamically allocating two page table entries from the "system" virtual address space table ... in such a scenario if the two (or more) processors were working with different kernel working buffers that happened to be in the same real page ... then for a short period of time, the "system" virtual address space table could have had two (or more) different page table entries pointing to the same real address. there was almost a plausable scenario in original 370 architecture where the "segment protection" (i.e. read-only, non-modifiable) was a bit in the segment table entry (i.e. the pointer to the page table for a specific segment). You could have the same (shared) segment at different virtual addresses in the same virtual address space .... where one version was "protected" and the other version was unprotected. Most threads in the address space would be accessing the r/o, protected version ... while some privilege thread might have access to the r/w, unprotected version. the original relational/sql implementation, system/r http://www.garlic.com/~lynn/subtopic.html#systemr did something of a flavor of this ... but the "threads" were running in different virtual address spaces ... not the same virtual address space.
From: Anne & Lynn Wheeler on 22 Dec 2006 12:52 "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> writes: > With 2.6, the kernel is mapped into all processes (as most other OS do) > but it may have retained some of that original mapping functionality > from previous versions for driver compatibility. modulo the virtual machine monitors ... dating back to cp40 in the mid-60s. MVS inherited global mapping from its real-memory ancesters ... which had paradigm that was also extensively pointer-passing (not only the kernel ... but all the subsystem services that existed outside of the kernel ... everything essentially existing in a single *real* address space). There was a difficult period for MVS before the move from 24-bit virtual address space to 31-bit virtual address spaces ... where the system mapping could take 12-13 of an application's virtual 16mbyte (in some cases leaving only 3mbytes for the application). for lots of topic drift ... While the MVS kernel got global mapping ... there was a problem with the non-kernel, semi-priviledged, subsystem services (things that might look like "demons" in other environments) ... which got their own individual "application" address space. The problem was that the paradigm was still extensively pointer-passing ... even between general applications and subsystem services. The initial cut was a "COMMON" segment ... something that appeared in all address spaces ... where an application could stuff some parameters and then subsystem service could access them using passed pointer. The next cut at addressing this was dual-address space mode .... actually having two active virtual address spaces simultaneously .... pointer was passed to subsystem service in a different address space ... and that subsystem service could use the pointer to reach directly into the application address space. The downside was that it still required a kernel transition to get to/from the subsystem service. Dual-address space was then generalized to multiple address space and the "program call" function was added. program call was hardware defined table of subsystem functions and some operations that happen (like how the virtual address space pointers change) ... it allows transition directly from application address space into subsystem address space (and back) w/o requiring a software transition thru the kernel, pointer-passing paradigm continues ... and there is now all sorts of cross virtual address space activity going on.
From: Anne & Lynn Wheeler on 22 Dec 2006 18:57 "mike" <mike(a)mike.net> writes: > It is interesting to observe how all this complexity disappears when > the kernel and all user processes exist in a single humongous virtual > address space as it does in CPF from the System/38...OS/400...i5/OS. > In that system all files, all programs, and every other type of object > is mapped into virtual memory and a read is just a page fault. There > is no program relocation and no mapping at all. > > Similar technology is used by an experimental system under development > by Microsoft R&D which is almost entirely written in C# and so called > "managed code" to provide higher levels of security than is possible > with traditional designs. modulo if you actually were to do straight-forward memory mapping and then actually demand page faulted every page in (4k transfer at a time). this is one of problems with tss/360 ... on 360/67 ... vis-a-vis cp67 with cms on the same hardware. even tho cms had many of the problems with program relocation and no paged mapped filesystem ... it would attempt to do program loading in up to 64kbyte disk transfers (instead of 4kbyte at a time on a demand page fault basis). tss/360 also had other issues, like bloat ... excessively long pathlengths as well as fixed kernel real storage requirements that possibly represented 80percent of total real storage (not only excessive demand page faulting but excessive fixed kernel size contributing to page thrashing) one of the things that i tried to do when i implemented page mapped filesystem for cms in the early 70s ... was to preserve the benefits of large block disk transfers for things like program loading ... and avoid regressing to single 4k at a time demand page faulting. http://www.garlic.com/~lynn/subtopic.html#mmap part of the trick is to have page mapping but still preserve paradigm supporting large block transfers (and minimize degenerating too much to 4k at a time demand page faults). for some trivia ... s/38 is supposedly some of the refugees retreating to rochester after the future system effort failed (future system including concept of one level store ... some of it coming from tss/360 effort) ... misc. future system postings http://www.garlic.com/~lynn/subtopic.html#futuresys of course even even after doing page mapped filesystem for cms .... there was still a large part of the infrastructure that was oriented around program relocation paradigm ... various postings on the trials and tribulations attempting to deal with those problems http://www.garlic.com/~lynn/subtopic.html#adcon
From: mike on 22 Dec 2006 20:33 "Anne & Lynn Wheeler" <lynn(a)garlic.com> wrote in message news:m3ejqrqyav.fsf(a)garlic.com... | | "mike" <mike(a)mike.net> writes: | > It is interesting to observe how all this complexity disappears when | > the kernel and all user processes exist in a single humongous virtual | > address space as it does in CPF from the System/38...OS/400...i5/OS. | > In that system all files, all programs, and every other type of object | > is mapped into virtual memory and a read is just a page fault. There | > is no program relocation and no mapping at all. | > | > Similar technology is used by an experimental system under development | > by Microsoft R&D which is almost entirely written in C# and so called | > "managed code" to provide higher levels of security than is possible | > with traditional designs. | | modulo if you actually were to do straight-forward memory mapping and | then actually demand page faulted every page in (4k transfer at a | time). | | this is one of problems with tss/360 ... on 360/67 ... vis-a-vis cp67 | with cms on the same hardware. even tho cms had many of the problems | with program relocation and no paged mapped filesystem ... it would | attempt to do program loading in up to 64kbyte disk transfers (instead | of 4kbyte at a time on a demand page fault basis). | | tss/360 also had other issues, like bloat ... excessively long | pathlengths as well as fixed kernel real storage requirements that | possibly represented 80percent of total real storage (not only | excessive demand page faulting but excessive fixed kernel size | contributing to page thrashing) | | one of the things that i tried to do when i implemented page mapped | filesystem for cms in the early 70s ... was to preserve the benefits | of large block disk transfers for things like program loading ... and | avoid regressing to single 4k at a time demand page faulting. | http://www.garlic.com/~lynn/subtopic.html#mmap | | part of the trick is to have page mapping but still preserve paradigm | supporting large block transfers (and minimize degenerating too much | to 4k at a time demand page faults). | | for some trivia ... s/38 is supposedly some of the refugees retreating | to rochester after the future system effort failed (future system | including concept of one level store ... some of it coming from | tss/360 effort) ... misc. future system postings | http://www.garlic.com/~lynn/subtopic.html#futuresys | | of course even even after doing page mapped filesystem for cms | ... there was still a large part of the infrastructure that was | oriented around program relocation paradigm ... various postings on | the trials and tribulations attempting to deal with those problems | http://www.garlic.com/~lynn/subtopic.html#adcon Lynn, As I am sure you know the S/38 needed a lot of tuning when it first came out. Over time file processing got a lot more efficient. The system now understands the difference between sequential and random processing and does block loads of N pages where appropriate. It also runs look-ahead threads to overlap file retrieval with processing which even accelerates random file processing. Further it knows to load a whole program rather than just 4k on first reference or after a long wait. The system is still not as efficient as S/360 and its children for big batch file processing but it isn't bad and the path length for conversational applications is actually pretty good. One great thing about the single level store is that code is never ever relocated in the virtual address space. This simplifies many issues for both kernel and user code. Mike Sicilian
From: Anne & Lynn Wheeler on 26 Dec 2006 04:32
"mike" <mike(a)mike.net> writes: > One great thing about the single level store is that code is never > ever relocated in the virtual address space. This simplifies many > issues for both kernel and user code. re: http://www.garlic.com/~lynn/2006x.html#26 Multiple mappings for a lot more (old) topic drift ... article predates os/400: Start-Up Firm To Test MVS Replacement From November 25, 1985 issue of Information Week Byline: Paul E. Schindler, Jr. ..... Key Logic's early users will get the chance to run one of the few alternatives to the basic IBM mainframe operating system. Although Amdahl Corp. sells a mainframe Unix called UTS, and may someday release a souped-up MVS-like operating system developed under the code-name Aspen, UTS is not new to the market and Aspen is not a radical departure. KeyKOS is both. It offers high performance, reliability, security, and programmer productivity, the company says. ..... Programmers continue to deal with the same hardware they have used for years. In a three-week course, they can learn how to program efficiently under KeyKOS using standard IBM programming languages. Experience indicates that programmers writing applications for KeyKOS produce 40% less code than do programmers for other operating systems, including IBM's MVS and VM. This kind of productivity is made possible by two new computing principles upon which KeyKOS is based. The first principle deals with communications. Programs, tasks, files, or even guest operating systems are all known as objects that communicate via messages. Objects cannot communicate with each other unless given the "keys" (Key Logic calls them capabilities) to do so. This ensures both security and reliability. A failure in one object cannot affect any other object, ensuring continued operation. The other principle deals with memory. As with IBM's System/38, for example, KeyKOS treats all main memory and disk storage as one virtual memory. Programmers do not have to deal with disk I/O routines or file management -- KeyKOS does. .... snip ... a few recent posts mentioning Aspen http://www.garlic.com/~lynn/2006w.html#24 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#28 IBM sues maker of Intel-based Mainframe clones GNOSIS was operating system for 370 originally developed from scratch by Tymshare and spun-off as KeyKos when M/D bought Tymshare. I was brought in to do evaluation of GNOSIS as part of that spin-off (I still have the old documentation). Recent posts mentioing GNOSIS and/or KeyKos http://www.garlic.com/~lynn/2006k.html#37 PDP-1 http://www.garlic.com/~lynn/2006m.html#34 PDP-1 http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's? http://www.garlic.com/~lynn/2006w.html#42 vmshare post mentioning coyotos/eros/capros as evolution of KeyKos http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS? |