Talk:Virtual memory

Thrashing

As noted, paging/swapping is not a required characteristic of virtual memory, so I moved the section on Thrashing to the Paging article. It also needs some cleanup. Guy Harris (talk) 09:09, 5 January 2008 (UTC)

I agree about 75% - the text you moved was too long and technical for Virtual memory. But the article does need to mention thrashing and say "for more info see ...": it's a well-know problem of virtual memory systems and, if we don't mention it, someone may be tempted to add another excessive explanation. I'm inserting a simple explanation with "for more info see ...". Philcha (talk) 12:40, 5 January 2008 (UTC)

Top image

What's the reason for trying to replace a 4 KB .png file with a 17 KB .svg image? Philcha (talk) 14:31, 29 May 2008 (UTC)

I believe it is because SVG images are scalable (they don't pixelate when the size is increased) so they are preferred over PNG. Rilak (talk) 07:13, 30 May 2008 (UTC)

Printed version, huh. Poor amazonian trees. --Kubanczyk (talk) 07:55, 30 May 2008 (UTC)

Virtual memory confusion

Having read the article for the first time, and the discussions here, it seems to me to be a total confusion about what virtual memory is. First of all, let's separate the subject of demand paging from virtual memory. Demand paging is a different topic. Second, virtual memory is not about fooling the program into believing it has more memory that physically exists in the machine, although that can be one side effect of the whole deal.

What virtual memory is all about is to fool a program that it is alone in memory space, and that the whole memory space is exclusively for use by that program. Memory space starts at address 0 (well, it can be elsewhere as well, if it makes more sense), continues with or without holes in it, but the memory is not shared with other uses/users. A program can't tell that it's virtual memory. It looks just like physical memory to it, and the same exclusive view is given to all programs that might be running concurrently on the same computer. Thus, the same virtual address for different running programs can (and usually will) map to different physical addresses. So programs with different contexts can all refer to the same virtual address, but will be talking about different physical addresses. That's all there is to it. Or one program can refer to the same virtual address, but make that address refer to different physical addresses, if the program can manipulate the translation between virtual and physical addresses.

Now, to make a few things clear. A PDP-10 have a virtual memory system. So do a PDP-11, and a bunch of other computers, none which fulfills the definition that this article have made previously. If this article were to be taken at face value, Unix didn't have virtual memory until 4BSD.

Also, given the ideas that virtual memory is a way of fooling a program that it has more memory than physically exists, the PDP-11 is a fine example of where that is not true. The virtual address space is only 16 bits, while the physical address space of the large PDP-11s are 22 bits. And yet, they also have a virtual memory system. Moreover, even though the hardware of a PDP-11 allows you to design a demand paging system, noone ever did (as far as I know). However, swapping was done. This might be a good time to point of swapping. Swapping is the process of writing out or reading back the whole process context and memory from a backing store. This is different from paging, in which individual pages are read/written, and the context of the process stays in memory. Page faults are a part of the demand paging system, and occur as a part of the execution of a process. Swapping is something that happens when the process currently is suspended (maybe just because a context switch, and maybe because it is waiting for some event to happen). A page fault can cause a process to temporarily be suspended. Swapping on the other hand is something the OS decides upon because either resource shortage needs larger amounts of resources to be freed immediately, or perhaps because it appears that the resources will not be referred to for a long period.

I'm not really a good writer, so I don't feel appropriate to actually rewrite this article, but it certainly feels like people have got the three concepts totally confused. But to summarize: virtual memory - make it appear as if the whole addressable memory is "yours". Demand paging - a way of having part of program memory actually be stored on secondary storage, without the program being aware of it (unless you count timing issues). Swapping - a way of freeing up resources.

Demand paging can partly solve the resource issues as well, but can also cause thrashing and resource shortage. Demand paging is also the way of making it look like you have more memory than physically exists in the computer. Virtual memory is fundamental mechanism that is required for demand paging to work, but virtual memory do not mean that you got to have demand paging, as have been demonstrated by a number of machines.

I'll be happy to reply to any questions you might have. /bqt@softjar.se --212.112.174.86 (talk) 17:33, 30 September 2008 (UTC)

An interesting set of comments. If you can provide reliable sources for any of these points, the article should incorporate them. However I don't think your definition of "virtual memory" = "to fool a program that it is alone in memory space" is any superior to "fooling the application that it has a single block of contiguous memory" - in fact I think your definition is narrower, and therefore more easily falsified bvy a counter-example. The artcile may have to face the possibility of multiple definitions of "virtual memory", as different companies took different approaches based in the early work in the field, and then used "virtual memory" as a marketing term for their specific approaches. --Philcha (talk) 10:54, 19 November 2008 (UTC)

What would be considered reliable sources? Processor handbooks describing the virtual memory system of any of the machines I mention? One "fact" that stands out in a computer using a virtual memory system is that you can have several programs running at the same time, referring to the same virtual address, but none of those programs are in fact referring to the same location as any of the other programs running. Virtual memory is a way of abstracting away a lot of details involving the operating system and multitasking. The running program don't have to be aware of that kind of detail nor have to take it into consideration when doing something. Also, if a program runs amok and trashes memory, it is only it's own memory space that gets trashed, no other process is affected by this. That is a very important aspect of virtual memory. It's just your own memory, and noone else have anything to do with it, nor is affected by anything happening to it. The fact that it might, or might not be contiguous is pretty irrelevant, and might or might not be true for any instance. As pointed out, the virtual memory can be implemented in a paged system where each page can be anywhere in physical memory. And yet, the page table can contain invalid pages in between valid pages. So, there is no base for the assumption that memory is contiguous either physically or virtually. But then again, there is really nothing that forbids it from being so. So, saying "fooling a program that it has a single block of contiguous memory" sets an arbitrary limit on what virtual memory is for which there is absolutely no factual base. My definition might not be perfect, but I believe it is far more correct than the current article, which basically just talks about a specific way of implementing virtual memory as if that was the definition of virtual memory. I wonder if you can find a single definition of virtual memory which would allow all processes private memory to be visible in all other processes running, as well as making the OS memory available. It would be a very interesting virtual memory to learn about. But I'm all ears. Oh, and I can't imagine how a system where all processes memory were visible to everyone else would work. Address space would cause limitations on how much could be in memory at the same time, two different processes running the same image would have that same image running at different addresses, or else the view of the memory would be presented differently for each program running (and how would that be done?). Also, what about dynamic memory allocation in the face of all this? I just can't see how you could get that to work. Virtual memory is really the only way to get past that hurdle. And it's all about presenting a private memory space as if noone else was around, no matter what else is happening in the system. /bqt@softjar.se --213.65.173.92 (talk) 01:02, 9 January 2009 (UTC)

Yes, the current definition, is historically inaccurate. The term "virtual memory" on many (if not most) of the early machines was used to describe a method to increase the total working set, not to provide some kind of C/Unix/flat memory model abstraction. That is why you see machines with flat address spaces (generally via segmentation) not being labeled as having virtual memory, and machines which didn't even have MMU's (early Mac OS) being described as having virtual memory. You have to remember the mindset was that physical memory was severely limited, and a machine which allowed you to simulate more of a scare resource was truly useful. Abstractions to make writing programs easier, weren't as much of a concern when you weren't even sure if it was possible to solve the problem. The B5000 widely credited as the first commercial machine with virtual memory did _NOT_ have a flat address spaces. The "processes" were accumulated disjoint sections of memory tied to individual data structures the application needed. What it did have, was the ability to transparently swap those regions to a secondary storage mechanism without application knowledge. —Preceding unsigned comment added by 12.166.178.178 (talk) 17:18, 5 December 2008 (UTC)

Since Unix is such a popular reference, I think it's rather appropriate that the PDP-11 is my source for objections most of the time. The PDP-11 is a 16-bit machine, meaning all addresses are 16 bits wide, and so on. However, the physical address space is 22 bits. Note how physical memory is much larger than virtual in a flat memory space. In addition, the PDP-11 do not have segment registers, or similar things. It have a MMU, a page table, and do page relocation. The 16-bit virtual address space is split into eight pages. Each page can be located anywhere in the 22-bit physical address space. So, for each process, the address space is a flat, virtual 16-bit address space. The MMU can set pages to not be accessible, and each page can also be a fraction of the full 8 KB. It don't need to map the whole 13 bits of address space. That's the basic concepts. With this, it would in theory be possible to write something with demand paging, or other page based virtual memory system on the PDP-11 (the MMU traps illegal memory references, and instructions can be restarted). But with only 8 pages, and loads of more physical memory than virtual, there isn't really much reason to make the effort. So, for all Unixes on PDP-11s, you do have virtual memory. And yes, it is there to present you with a flat virtual address space of 16 bits (so it was/is definitely for writing programs easier). But no, it is not page based, page driven, neccesarily contigous (either physically or virtually), or in any sense of the world a way to express that you have more virtual memory than physical memory on the machine. In the case you start having so many processes that physical memory still don't suffice, then swapping is used, to move whole jobs in and out of the swap area. So either a job is runnable, and then all memory referenced are in memory, or the job is swapped out, in which case parts might be in memory, and parts in the swap area. Anything describing virtual memory, which defines the Unixes (and other OSes on PDP-11s) as not having virtual memory just means they define virtual memory in a too restrictive way, or even plain wrong. /bqt@softjar.se 74.125.57.33 (talk) 15:05, 26 March 2010 (UTC)

Many virtual memory implimentations support shared memory, e.g., MULTICS, z/OS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:28, 15 June 2010 (UTC)

And some virtual memory implementations provide a single address space, possibly larger than the physical address space of the machine, in which all processes/tasks run, e.g. OS/VS1, OS/VS2 SVS, and the System/38 and AS/400 operating system. Guy Harris (talk) 09:31, 16 August 2011 (UTC)

Sigh, I see that the page have degenerated again, and once more claims that virtual memory is the same thing as paged memory. Do people really want Wikipedia to be this inaccurate? There are plenty of historical documents (such as PDP-11 processor handbooks to name one) which describes virtual memory, and which totally disagrees with what this page now talks about. Virtual memory is *not* the same thing as paged memory. Either can exist without the other. And I'm very curious to hear what the vm=paged-memory proponents would call the virtual memory of a PDP-11? /bqt@softjar.se 95.206.17.113 (talk) 14:48, 25 December 2012 (UTC)

FWIW, the Burroughs B5000, B5500 and B5700 had virtual memory but did not have paging. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:33, 27 December 2012 (UTC)

Virtual memory is also not about "to fool a program that it is alone in memory space, and that the whole memory space is exclusively for use by that program. Memory space starts at address 0 (well, it can be elsewhere as well, if it makes more sense), continues with or without holes in it, but the memory is not shared with other uses/users." As I noted, some systems run all processes in the same virtual address space - and this is not just some old technique superseded by giving every process its own address space; see some of the OSes listed in single address space operating system, such as IBM i and Singularity. Guy Harris (talk) 21:50, 25 December 2012 (UTC)

Removal of first part

I removed the following part:

Where is it? and how to change it?

In Windows XP go to "My Computer" > Right click on white part then "Properties" > "Advanced" tab > in Performance Box click "Settings" > Virtual Memory box "change"

All this is stored in a File named PAGEFILE.SYS

Wikipedia is not a howto ! (and the writing style is pretty poor) --G.ardaud (talk) 08:15, 19 November 2008 (UTC)

"Developed for multitasking kernels" not right?

Apologies if I've reverted prematurely. I was very much under the impression that is exactly what virtual memory and paging functions were about. And throw memory protection in there too.

Having now read more about the early mainframes and research computers I am now getting the impression that the executable was often streamed through RAM like the RAM was a cache. Is caching a good analogy?

If so, then I can see why the paging idea was an important step independent of multitasking. That said, I suspect such functionality can be achieved with just software when not multitasking.

Evanh (talk) 12:09, 21 November 2009 (UTC) Edited for clarity Evanh (talk) 14:10, 21 November 2009 (UTC)

The claim is not exactly wrong, but it at least overstates the relationship between VM and multitasking OS.

To put it as generally as possible: VM was developed to allow a workload to proceed as if all of the address space it had defined was present in the memory directly addressable by the instruction set, even though the actual RAM available to that workload was smaller than "all of the address space it had defined," and without the workload having to manage the memory by itself.

It doesn't really matter if the workload involves multitasking or not.

Consider VM as an alternative to the old scheme of code overlays, where the workload is responsible for calling the overlay functions to bring in various blocks of code. VM has the same effect, except that it works at a much finer granularity, and it works automatically, and of course it works for data regions too.

Now it is certainly the case that much of what we regard as the foundations of actual, realized, modern implementations of VM were developed as part of multitasking kernels. This may or may not be an accident of timing: there have been darned few significant, truly single-tasking kernels in the past few decades. And VM and multitasking do work very nicely together, as VM allows the kernel to effectively share the common memory resource across all of the tasks.

But as the article stands now, I think it's overstating the relationship between the two.

Re "cache", that IS a good analogy. The RAM is a cache for the most interesting things that are on the disk - automatically managed by the VMM. The CPU's internal cache is a cache for the most interesting things in RAM, the CPU's registers (the ones accessible to the instruction set) are a cache for the most interesting things from the internal cache, and the register file (seen only by the microcode) acts as a cache for those... Jeh (talk) 23:06, 26 June 2010 (UTC)

Burroughs large systems did have paging

While the B5000, B5500 and B5700 only had segmentation, the large B6500 series had a completely different architecture, which included both paging and segmentation.

FWIW the Unisys line includes only the B6500 architecture, not the B5000 architecture. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:34, 15 June 2010 (UTC)

Virtual=real has major errors

In IBM's OS/VS1, OS/VS2 (SVS) and MVS, V=R played a very limited role. The system had provision for temporarily page fixing storage, including I/O buffers; that was not something added in later releases. Programs using Execute Channel Program (EXCP) and building their own channel programs did not have to run V=R; the I/O Supervisor did the necessary page fixing and CCW translation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:54, 27 June 2010 (UTC)

Base and bound is not segmentation

A recent edit refered to segmentation as synonymous to segmentation; that is incorrect. With base and bound a program has access only to a single contiguous instruction area and to a single contiguous data area. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:47, 5 July 2010 (UTC)

I guess you meant "A recent edit refered to base and bound as synonymous to segmentation"? Jeh (talk) 01:54, 14 July 2010 (UTC)

Yes; thanks.

One minor correction is that some systems had separate storage areas for instructions and data. I'm not sure whether mention of that would be TMI in the article.Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:42, 15 July 2010 (UTC)

Level of detail for edge cases and nonstandard nomenclature

I have some policy questions inspired by the Burroughs B5000 and B6500 product line, but which probably apply to other architectures as well.

• Is it appropriate to mention occasional nonstandard nomenclature, e.g., the use by Burroughs of the term segmented to refer to the splitting of a large segment into independently mapped 256 word pages?

• Is it appropriate to mention techniques such as nested segments, or is that TMI.

• Is it appropriate to provide citations for some of the anomalies but to not mention them in the narrative? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:14, 6 July 2010 (UTC)

Virtual memory traits

Two features of some virtual memory systems that it might be appropriate to discuss in the introduction are that it is common to have provision for shared virtual memory and that some virtual memory systems have more flexible access controls than is feasible without address translation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:12, 22 July 2010 (UTC)

Hardware support for emulators and virtual machines

It is certainly common to write simulators without hardware support, but I am not aware of any emulator for a system with virtual memory that does not have hardware memory mapping for the emulated system, and I am not aware of any virtual machine facility that does not use hardware memory mapping for the virtual machine.

Note that emulation was defined as a combination of host software, microcode and hardware, not as simulation using only the standard host instruction set. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:19, 22 July 2010 (UTC)

An emulator produces the same results as the original equipment had achieved. A simulator fools the application into thinking the same results have been achieved without actually doing anything. Evanh (talk) 00:43, 1 September 2010 (UTC)

I have to agree with Chatul here. Virtual machines especially rely on heavily MMUs if they are any good. (i.e. they try their best to run the code natively, and react to hardware faults.) I would expect any emulator that needs to support an MMU would do the same, unless they wanted to be really slow, i.e. run tons of extra code at every memory access. 71.35.184.60 (talk) 22:36, 10 September 2011 (UTC)

Where to discuss channel program translation

{{Helpme}} In several lines of IBM mainframes, e.g., z/OS, an unprivileged application can prepare its own channel program and request its performance with the EXCP (Execute Channel Program). EXCP performs functions such as page fixing, address mapping and channel program translation. As the article is currently structured I don't see a good place to describe EXCP or similar facilities in other systems. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:01, 22 July 2010 (UTC)

We already seem to have an article at Unit Control Block. You could try including it in the "history" section if it's a function which arose with a particular system. Ironholds (talk) 14:37, 22 July 2010 (UTC)

I have only vague notions of IBM's channels and channel control programs. But I believe this function is in what is commonly referred to these days as an I/O MMU (I/O Memory Management Unit). Jeh (talk) 19:53, 22 July 2010 (UTC)

Hmn. I'd suggest asking at Wikipedia talk:WikiProject Computing; it's rather a specialist question. Ironholds (talk) 00:17, 23 July 2010 (UTC)

The material that I want to add is software, not hardware. There is no I/O MMU on IBM's flagship mainframe line, althugh there once was a facility called ECPS:VSE that provided the functionality in microcode. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:52, 25 July 2010 (UTC)

There's already material in the UCB article that I've suggested removing. CCW translation doesn't belong there either. I'll take Ironholds's suggestion and ask in Wikipedia talk:WikiProject Computing. Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:52, 25 July 2010 (UTC)

Seems good. —fetch·comms 01:55, 26 July 2010 (UTC)

I got around to reading this section only after I changed the article Channel_I/O to include a section on CCW translation, but that still seems the appropriate place for it to me. Peter Flass (talk) 19:33, 6 March 2012 (UTC)

Paging page tables

I've just tagged as dubious an assertion that page tables are not usually paged. There is no source for that assertion and certainly pages tables may be paged. I can't cite any particular systems off the top of my head but I remember covering this distinctly at Uni over ten years ago. Although it does complicate memory management it is not insurmountable and I was under the impression that is was common practice for a full-featured implementation. I'll start up up some particular systems but the "usually" element is always going to be problematic. Does anyone have any sources for that assertion? Crispmuncher (talk) 14:16, 22 July 2010 (UTC)

On Windows x86/x64, all but the top-level table (PD without PAE, PDPT with PAE, PML4 on x64) can be paged. VAX did not use multilevel PTs but the P0 and P1 page tables can be paged, while the system PT cannot be. So, yes, at least some page tables can certainly be paged, and indeed this is done in the most widely used OS in the world. Jeh (talk) 19:51, 22 July 2010 (UTC)

Windows is not even close to the most widely used OS in the world. It is merely the most widely used DESKTOP OS in the world. More over, that doesn't invalidate the point; many page tables STILL cannot be paged. The fact SOME can doesn't mean anything to the statement made. —Preceding unsigned comment added by 130.85.56.86 (talk) 23:26, 9 November 2010 (UTC)

Regardless of what the most widely used OS is (a point that as far as I can tell was never raised and was never in contention), the claim vastly overstated the case. Corrected. Jeh (talk) 19:03, 17 November 2010 (UTC)

"Page tables are usually so large that they are stored in main memory and are sometimes paged themselves" From "Computer Architecture: A Quantitative Approach 4th Ed" by John L. Hennessy and David A. Patterson, Appendix C p. C-44.

Prevalence of virtual memory operating systems in the 1960′s and early 1970's

The claim Consequently, older operating systems (such as DOS of the 1980s or those for the mainframes of the 1960s) generally have no virtual memory functionality is questionable. Even if you exclude block relocation as not being virtual memory, at least the following vendors shipped commercial paging computers in the 1960's:

• CDC
• DEC
• GE/Honeywell
• RCA
• SDS

Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:53, 17 November 2010 (UTC)

"Generally" is probably true. The only DEC boxes with paging in the 1960's were the ones with the add-on BBN pager, and the IBM System/360 Model 67, GE 645, SDS 940, and RCA Spectra 70/46 were all special variants of the S/360, GE 600, SDS 900, and Spectra 70 lines. What was the paging CDC machine of the 1960's?

Paging definitely was mainstream by the early '70's, however, given S/370 and {DOS,OS}/VS. Guy Harris (talk) 23:21, 5 July 2011 (UTC)

Even if you ignore paging models of otherwise non-paging product lines, you have

• CDC STAR-100
• Ferranti Atlas and Titan
• SDS Sigma-7

Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:10, 15 August 2011 (UTC)

The CDC STAR-100 was, at least according to the Wikipedia article for it, "announced very early during the 1970s" and "first used commercially in 1974", so it doesn't sound like a paging computer of the '60's. According to the page for the Ferranti Titan, it "had a real, but cached, main memory, rather than the paged (or virtual) memory used in the Manchester [Atlas] machine". So, for the '60's, we have:

• Atlas (about which I already knew, and of which only 3 were built, according to the Wikipedia article)
• PDP-10 with the BBN pager added (which I mentioned above)
• GE 645 (which I mentioned above)
• IBM System/360 Model 67 (which I mentioned above)
• RCA Spectra 70/46 (which I mentioned above)
• SDS 940 (which I mentioned above)
• SDS Sigma 7

most of which were, as I stated above, special variants of a general line of computers of which most shipped, as far as I know, without virtual memory - the only exceptions were the low-volume Atlas and the Sigma 7. So I've not seen anything to indicate that one should not state that "older operating systems (such as ... those for the mainframes of the 1960s) generally have no virtual memory functionality"; nobody's given any statistics showing that, of the systems shipped in the 1960's, either a majority or significant minority had VM hardware and software. The 1970's were, as I indicated above, different - but the page doesn't say "of the 1960s and early 1970s, it just says "of the 1960s". Guy Harris (talk) 23:08, 15 August 2011 (UTC)

The SDS 940 and Sigma systems in the 60s had virtual memory. If you want to count boxes, IBM outweighs everyone else, but if you want to count systems or families, I'd say maybe many older operating systems..." Peter Flass (talk) 00:31, 27 October 2011 (UTC)

At this point, if you include non-vendor OSes, the '60's-vintage OSes I know of that supported VM are:

• the Atlas Supervisor for the Atlas;
• TENEX for the PDP-10 with the BBN pager added;
• Multics for the GE 645;
• TSS/360 and CP/CMS for the IBM System/360 Model 67;
• TSOS for the RCA Spectra 70/46;
• the Berkeley Timesharing System for the SDS 940;
• UTS (and anything earlier?) for the Sigma 7.

(any similarity between that list and the above list of machines supporting VM is not coincidental :-)). In terms of a raw count of OSes, regardless of how many instances were shipped, is that enough to rule out "generally"? (If you count systems shipped, I suspect you can't rule out "generally".) Guy Harris (talk) 07:07, 27 October 2011 (UTC)

Argh! I forgot the Burroughs B5000, the first machine to have segmented virtual memory.

You also had block relocation from, e.g.,

• CDC
• DEC
• GE/Honeywell
• UNIVAC Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:40, 27 November 2017 (UTC)

Unless the relocatable blocks don't all have to be in main memory, and a reference to a block not in memory causes a fault that's resolved by bringing it into memory, I wouldn't consider transparent relocation to be virtual memory. Guy Harris (talk) 19:01, 27 November 2017 (UTC)

Meta: {{Page needed}}

The is a reference for Virtual=Fixed (V=F) that is tagged with {{Page needed}}; however, that template is inappropriate because the reference does not have page numbers. I wanted to replace the {{Page needed}} template with a more appropriate one, but I couldn't find a template for subsection URL needed. There are other references for V=F. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:53, 17 November 2010 (UTC)

On suitable reference is "Central Storage Considerations for User Programs". z/OS V1R11.0 MVS Programming Assembler Services Guide z/OS V1R10.0-V1R11.0. SA22-7605-11. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:45, 9 February 2011 (UTC)

PDP-10 and Virtual Memory

"To allow for multiprogramming and multitasking, many early systems already had the ability to divide the memory between multiple programs even without providing virtual memory; for instance, early models of the PDP-10 provided memory access through what are called base and bounds registers."

The "early models" of PDP-10 you are talking about are the KA10 processor and its predocessor the model 166 processor of the PDP-6 computer. The later models (KI10, KL10, KS10) all had demand paging virtual memory management. However, the idea that the KA10 didn't provide virtual memory is wrong. It provided a two segment memory model (shared and private) via two sets of base, protection, and length registers. Every user memory address was automatically translated as part of access and every process (job in tops-10) had its own image of memory. This is virtual memory.

what is virtual memory pracically? —Preceding unsigned comment added by 59.180.178.40 (talk) 16:56, 23 February 2011 (UTC)

I'd say a key characteristic of virtual memory is that, on a system with virtual memory, a single process (or equivalent) can run in an address space larger than the machine's physical memory. If all the pages/segments of a process (job, task, whatever) must be in memory in order for the process to be runnable, I wouldn't call that virtual memory, even if the OS swaps jobs in and out of memory, so that the sum of the sizes of all the processes on the system is greater than the machine's physical memory. This wouldn't include the KA10 and the TOPS-10's that ran on them, but it would include paging systems as well as segmenting systems that don't require all of a process's segments to be in main memory and that can dynamically fault segments into memory and move them out of memory. Guy Harris (talk) 23:34, 5 July 2011 (UTC)

Note that, given, for example, OS/VS1 and OS/VS2 SVS, this could be done without giving each process its own virtual address space; they packed multiple processes into a single virtual address space, in the same way their predecessors packed them into the physical address space. The virtual address space could presumably be bigger than the machine's physical address space, so you could still have a process (job) run that wouldn't fit in physical memory. Guy Harris (talk) 23:43, 5 July 2011 (UTC)

Base and bound is virtual memory.

If the system has base/bound registers, for example the early ICT 1900 series then user programs do not manipulate physical addresses they manipulate virtual addresses.

Or, to look at it another way base/bound is a degenerate case of segmentation -- the process only has one segment. (Or two on PDP 10). HughesJohn (talk) 11:05, 23 March 2011 (UTC)

See my comment in the PDP-10 section above; I'd say virtual memory needs more than relocation and protection, it needs to let a process run even if all of its address space isn't in main memory, with pages/segments/whatever dynamically pulled into memory as the result of a "not present" fault and other pages/segments/whatever evicted, if necessary, to make room for them. Perhaps there needs to be a term for relocation+protection, but if that term is "virtual memory", another term is needed for relocation+protection+not all the address space needs to be in main memory (and "paged virtual memory" isn't it, as that doesn't include segment swapping). Guy Harris (talk) 23:38, 5 July 2011 (UTC)

"I'd say virtual memory needs more than relocation and protection, it needs to let a process run even if all of its address space isn't in main memory,"

Why?

I'd say that a virtual memory means virtual addresses. In a virtual memory system programs don't manipulate real addresses, there is some translation from virtual addresses to real addresses. To me base and bound is a degenerate version of segmentation - base/bound system only allows one segment per program. HughesJohn (talk) 16:31, 28 October 2011 (UTC)

There needs to be a distinction between "instruction and data addresses are not physical addresses in main memory, but all of the addresses in the address space need to have a physical address in main memory to which they correspond" and "instruction and data addresses are not physical addresses in main memory, and not all of the addresses in the address space have to have a physical address in main memory to which they correspond - a reference to a location that doesn't have such a physical address will cause a physical address to be assigned to that location (and presumably some part of the address space near that location) and the appropriate bits put there". If there's a consensus that "virtual memory" should refer to the former (and that consensus is supported by the way the term "virtual memory" is actually used in computer engineering!), then this page needs a lot of reorganization, possibly including creating a page for the latter. (A distinction might also be desired between "swapping" in the sense of a system where a process/application/whatever needs to have all its address space in main memory when it's running, but a process that's not running could have some or all of its core and data in secondary storage, with that code and data moved into main memory when the process is scheduled to run.)

I.e., there's "virtual" as in "not equal to physical" and "virtual" as in "not necessarily in physical memory"; the latter implies the former (although I suppose I might be missing a system where, for example, demand paging makes sense when a given non-resident page always gets paged into the same physical page, and that page is unusable except by that particular page), but involves a lot more than just the former. Guy Harris (talk) 17:50, 28 October 2011 (UTC)

"If there's a consensus that "virtual memory" should refer to the former (and that consensus is supported by the way the term "virtual memory" is actually used in computer engineering!), then this page needs a lot of reorganization."

It's pretty clear to me that this page needs rewriting. I mean, look how it starts "In computing, virtual memory is a memory management technique developed for multitasking kernels.". Bleaurgh, a-historical nonsense. I'm looking for good references. HughesJohn (talk) 14:26, 29 October 2011 (UTC)

No, "instruction and data addresses are not physical addresses in main memory, but all of the addresses in the address space need to have a physical address in main memory to which they correspond" is 'not the way the term "virtual memory" is actually used in computer engineering!); the way that it is actually used is that pages in the auxilliary (paging) files do not have corresponding real storage addresses.

BTW, I am aware of one case where pages are remapped without any involvement with the normal paging mechanism; it's called prefixing and causes translation of real address 0 to an absolute address associated with the processor. I don't consider prefixing to be virtual storage, but others may disagree.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:40, 1 November 2011 (UTC)

Systems using memory map registers

This discussion doesn't cover systems that implement virtual memory via memory map registers rather than page tables. I'm thinking of the SDS 940 and Sigma systems, but I imagine there are others.Peter Flass (talk) 00:26, 27 October 2011 (UTC)

Sun-1, Sun-2, Sun-3 (except for Sun-3x), Sun-4 (prior to the Sun-4d and Sun-4m). Guy Harris (talk) 04:29, 27 October 2011 (UTC)

I believe that the CDC 3800 used memory map registers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:42, 1 November 2011 (UTC)

Was it the SDS 940 that did paging? My recollection is SDS 945. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:06, 12 December 2011 (UTC)

According to this section of a Web article:

By February 1966, SDS announced the SDS 940, a time-sharing system which was backward compatible with the previous systems (except the SDS 92 which was a 12 bit computer). It had monitor and user modes, dynamic program relocation, automatic memory fragmentation, and system protection. "You'll still be contented using your 940 system five years from now" - was advertised in 1966. Today (1984) SDS 940s still run Tymshare's Tymnet and Comshare uses at least two. The University of California at Berkeley worked with Tymshare and SDS on this early time-sharing system.

In 1968 the SDS 945 was advertised as an SDS 940 with less expandibility but just as much compute power. The design of the SDS 940 is very complex because of the backward compatibility with the 930 etc. and the needed changes to support time-sharing. The design of the Sigma 7 can readily be seen as a simplification and extension.

so it sounds as if they both did paging. Guy Harris (talk) 20:21, 12 December 2011 (UTC)

paging-predominant?

Segmented virtual memory: "systems with this memory structure, such as Multics and IBM System/38, are usually paging-predominant." 1) What exactly does this mean? 2) What is/are other alternatives and who uses them? This sounds like an interesting concept that is dropped in here with no amplification.Peter Flass (talk) 13:54, 10 November 2011 (UTC)

Embedded situations

The part about embedded systems doesn't really make sense, especially the part about bit-banging. (If you have a real-time system and use a system where a page fault could trigger I/O (e.g. you are using a demand paging system), you have a significantly bigger problem than merely the fact that you are using bit-banging for I/O accesses. (Wikipedia newbie, non-registered user) — Preceding unsigned comment added by 90.228.211.236 (talk) 19:51, 28 December 2011 (UTC)

I completely agree, and have removed the mention of bit-banging. I tried to replace the sentence that I removed with further explanation, but it ended up being redundant to what was already said, so I decided to simply remove the final sentence. A highly significant number - perhaps the vast majority - of embedded designs do not use bit-banging, and yet they still have timing-critical algorithms where VM might cause failure due to timing variations. (In hind sight, perhaps it's worth mentioning that VM is expensive, both in cost and in transistor count, and that's a big reason why VM is missing on embedded systems) BrianWilloughby (talk) 23:21, 18 January 2018 (UTC)

I presume they were concerned with a page fault occurring during bit-banging, but, as noted, a page fault occurring when doing anything time-critical could cause a problem. It's not just I/O, so I removed the mention of I/O operations, and noted that it's not just trap overhead - if the page fault requires that a page be read in from secondary storage, that's a real problem in time-critical code.

Furthermore, an embedded system might not have secondary storage from which to page, which would be another reason not to use VM. Guy Harris (talk) 00:30, 19 January 2018 (UTC)

Virtual memory, whether using paging or segmentation, can still be useful in an embedded system as a way of managing storage allocation. If you have multiple heaps or stacks, you can make them large without needing enough real storage to back them all up concurrently. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:34, 19 January 2018 (UTC)

That section doesn't say that embedded systems don't use virtual memory, it says that they may not use it. If "embedded system" means "system with a CPU that doesn't have support for running third-party software and that doesn't do general-purpose computing", that could range from a small controller inside a medical device (where a failure to respond to a signal within a critical interval might be life-threatening) to a TiVo box (where a failure to respond to a signal within a critical interval means you may get a glitch when watching your favorite TV show). I think the latter run Linux and probably do paging.

Also, the requirement for time-critical response doesn't necessarily mean the entire system must avoid using virtual memory. If, for some embedded system, the processor includes memory mapping hardware, and the system has enough memory to support an OS that can do paging, and the OS does support paging, if that system needs some code to support time-critical response in less time than would be required to handle a page fault, it might just wire down all the code in the code path for time-critical responses, and all the data required by that code, and allow only code that's not time-critical, and the data it uses, to be paged. Guy Harris (talk) 18:07, 19 January 2018 (UTC)

Fragmentation

On 15 February 2012 Daniel Santos said "(Removing old unsourced claim. I do not believe it's true, but if somebody wants to get a good source on it, then they can re-add it. Efficiency gains from reduced fragmentation can be offset by the overhead of memory mappings and context switching.)"

I think the claim was the VM systems use "hardware memory" more efficiently, not necessarily the whole system. I don't have a source handy, but consider a system like MVT that needed contiguous physical memory equal to "region size" before starting a job. Large chunks of memory might have to sit unused waiting for something to end to free enough contiguous storage. A system like MVS would be able to start the job immediately and fill up physical memory with the working sets of all active jobs.

Of course this caused other problems, but memory sure could be fully used. Peter Flass (talk) 13:22, 15 February 2012 (UTC)

The validity of the claim is not limited to VM; in fact, you mention MVS, which is an example of a system using hardware memory more efficiently than its real predecessor, OS/360. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:02, 1 March 2012 (UTC)

(By "The validity of the claim is not limited to VM" do you mean "VM" as in "virtual memory" or as in "virtual machine"?) Guy Harris (talk) 00:37, 2 March 2012 (UTC)

I was talking about virtual memory, I thought that was what the original claim was about... Peter Flass (talk) 13:04, 2 March 2012 (UTC)

My question was asking what User:Chatul meant by "VM" in "The validity of the claim is not limited to VM"; if he meant "virtual memory", that statement makes no sense to me, given that MVS supported demand-paged virtual memory, so MVS had "VM" in that sense, so I was wondering if he thought "VM systems" meant "systems running VM" rather than "systems with virtual memory". Guy Harris (talk) 17:48, 2 March 2012 (UTC)

I took VM to be a reference to VM (operating system) rather than to Virtual machine or Virtual memory . Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:57, 2 March 2012 (UTC)

Embedded Systems Complex Memory Hierarchy Reference

Removed an uncited sentence asserting that embedded systems don't need a complex memory hierarchy as per WP:FORUM Random2001 (talk) 21:13, 7 March 2012 (UTC)

Terminology for pages locked into physical memory

Just for fun, I took at look at the mlock() man page in OS X, and it mainly uses "locked (into memory)". The HISTORY section of the man page says "The mlock() and munlock() functions first appeared in 4.4BSD.", so the *BSD man pages probably are the same or very similar. The Solaris and HP-UX pages also speak of locking pages in memory. The Linux mlock() page speaks of "disabling paging", and the AIX page speaks of "[causing] those whole pages containing any part of the address space of the process starting at address addr and continuing for len bytes to be memory-resident until unlocked...".

So I'm not sure for which operating systems the term is "pinned". This question speaks of "pinned pages" on AIX; I'm not sure the output with "pinned" in it is from an AIX command or not. OS X's Activity Monitor uses "wired", but I don't know offhand whether those pages are only pages "wired" by virtue of being, for example, kernel code or data pages, or whether it includes pages locked into memory because I/O is being done to or from them or if they've been mlock()ed. This knowledgebase entry for VMware speaks of "pinned pages (sometimes called locked pages)". Guy Harris (talk) 21:58, 26 May 2012 (UTC)

A reference for the term page fix in z/OS and earlier systems is z/OS V1R12.0 MVS Programming Authorized Assembler Services Guide, SA22-7608-15 Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:01, 1 June 2012 (UTC)

Question on Referencing My Own Book

I recently published a book on the internals of the virtual memory manager of Windows and I would like to know if I am allowed to add a bibliographic reference to it on this page.

I have a personal interest a stake, because I would like as many people as possible to know that my book exists. At the same time, I think readers of this article would benefit from this information, since the book is relevant to the subject at hand.

In the event that I am allowed to add such a reference, would it be correct to place it in the Further Reading section?

Below are the book reference data, thanks.

Title: What Makes It Page? Author: Enrico Martignetti Publisher: CreateSpace Independent Publishing Platform Publicaton date: August 21, 2012 ISBN-10: 1479114294 ISBN-13: 978-1479114290 EnricoMartignetti (talk) 15:46, 19 February 2013 (UTC)

It is allowed, but please follow these guidelines: https://wiki.riteme.site/wiki/Wikipedia:Attribution#Citing_yourself Ehamberg (talk) 21:22, 19 February 2013 (UTC)

Thank you, I have read the guidelines and I have a further question: my book is self-published and it's my only publication, so I cannot claim to be a recognized expert in this field. However, the book is receiving positive evaluations, including two customer reviews on Amazon, ranking it at 5 out of 5 stars. Given all this, can I still add it to the Further Reading section? I am convinced that the book content is relevant, so my misgivings are only about it being self-published. Thanks again. EnricoMartignetti (talk) 13:51, 20 February 2013 (UTC)

I am about to add my book to the Further Reading section. I believe this is a useful piece of information for readers interested in this subject.EnricoMartignetti (talk) 11:05, 4 March 2013 (UTC)

Sorry your book listing looks like self-promotion to me. I think it would be more likely to be acceptable if you had referenced your book in some part of the article itself. But simply listing it as further reading seems like advertising, and as the author you should probably not be the one doing that. — Preceding unsigned comment added by Gabriel.Southern (talk • contribs) 23:40, 22 May 2013 (UTC)

Virtual memory does not imply paging

While it is true that the first computer with a virtual memory, the Ferranti Atlas, used paging, it was quickly followed by the Burroughs B5000, which used segmentation but not paging. The recent revision to the introduction of Virtual memory defines virtual memory strictly in terms of paging. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:37, 6 August 2013 (UTC)

Agreed. Reverted. Jeh (talk) 18:14, 6 August 2013 (UTC)

OTOH I don't really like the current text either - I think it's long-winded. Peter Flass (talk) 18:41, 6 August 2013 (UTC)

The intent of my change was to describe virtual memory in terms of address translation in hardware coupled with software that can extend the capabilities of the hardware, something the current text fails to do. While there have been various hardware implementations that do not use pages, most do, since that methodology easily extends the capability to demand paging. IBM's first machines with VM used segmentation tables and page tables, but so what? Most people reading the article will be totally confused by the complex address translation. The main intent of my article was to stress that memory withing the hardware can be addressed in two ways: real and virtual. If you all feel that selecting page tables as an example of how to to do that was inappropriate, then why not follow the idea of trying to write a coherent explanation and modify what I said.

I would be hard pressed to decide what are the greatest benefits provided by VM. Certainly demand paging would appear as the most useful in single user systems and the combination of discreet address space and demand paging in multi user systems. Discreet memory today would probably be useful without demand paging, since we have 64 bit memory addresses and cheap memory. In the days when VM was designed, 64K cost millions of dollars, so the ability to use that memory more efficiently was far more important than discreet addressing. The early 360 models were multi user, but did not have virtual memory. Those systems used memory protection with a protection key assigned to each task. The model 67 used virtual memory, but did not come into being until later in the life of the 360, the computer that dominated the entire world. IBM needed a way to provide more memory without driving the cost to prohibitive levels. VM provided the methodology to accomplish that and allowed IBM to sell many more computers. The impact of this significantly enlarged IBMs market and changed the way corporations handled large amounts of data. The ability to provide more memory at no additional cost had much greater historical impact on the computer industry than discreet address spaces. Andiamo1 (talk) 09:53, 10 August 2013 (UTC)

Giving paging as an example of VM is OK. Saying

It allows memory to be addressed using a set of hardware tables that provide a view of memory that is contiguous even though the pages that make up real memory are discontiguous . In other words, the memory appears to be in a set of pages that are addressed using an address counter that is incremented sequentially from the lowest to the highest memory address.

doesn't give it as an example, it gives it as an required aspect; in systems with segmented and unpaged virtual memory, real memory isn't made up of pages, and the memory doesn't appear to be in a set of pages, but the system nevertheless has virtual memory. Guy Harris (talk) 19:29, 10 August 2013 (UTC)

How about this?

"In computing, virtual memory is a memory management technique that is implemented using both hardware and software. It maps memory addresses used by a program, called virtual addresses, into physical addresses in computer memory. Main storage as seen by a process or task appears as a contiguous address space or collection of contiguous segments. The operating system manages virtual address spaces and the assignment of real memory to virtual memory. Address translation hardware in the CPU, often referred to as a memory management unit, automatically translates virtual addresses to physical addresses. Software within the operating system may extend these capabilities to provide a virtual address space that can exceed the capacity of real memory and thus reference more memory than is physically present in the computer."

Peter Flass (talk) 13:30, 10 August 2013 (UTC)

I think it's good. In any case, it's a substantial improvement over what is on the public page. I also think it's important to provide some history and emphasize that VM's ability to extend real memory had much more of an impact on computing than just a virtual address space. Andiamo1 (talk) 19:36, 10 August 2013 (UTC)

Software within the operating system may extend these capabilities to provide a virtual address space that can exceed the capacity of real memory and thus reference more memory than is physically present in the computer. "Software" is enabling the pagefile.

@ Andiamo1

Virtual Memory does not extend real memory, more RAM extends real memory. VM is secondary level storage for the CPU, primary being RAM. So yes VM increases address space, and allows a 32bit CPU to execute 64bit instructions, as long as 64GPR's are present. Which is how IA-32e/Intel64 runs 64 bit OS - the pagefile must be enabled. RAM is still limited by the address bus.

Also: While Virtual Memory doesn't imply paging, it does imply a pagefile. Without a PF there is no Virtual Memory. Therefore I feel x64 Demand Paging should be clarified as mutually exclusive,.....

Giving paging as an example of VM is OK.::::

@Guy

Not really. Virtual Memory is a Hard Drive used as CPU secondary storage, primary being RAM. Paging describes the method by which data is moved between CPU/RAM and HDD regardless of whether Virtual Memory is enabled or disabled. When VM is enabled obviously paging is enabled also.

It allows memory to be addressed using a set of hardware tables that provide a view of memory that is contiguous even though the pages that make up real memory are discontiguous .

In other words, the memory appears to be in a set of pages that are addressed using an address counter that is incremented sequentially from the lowest to the highest memory address doesn't give it as an example, it gives it as an required aspect; in systems with segmented and unpaged virtual memory, real memory isn't made up of pages, and the memory doesn't appear to be in a set of pages, but the system nevertheless has virtual memory. ::::

@Guy: They're called page tables. And "Segmented unpaged" describes legacy x86. - why not just say that? Why make things so overcomplicated? Paging is not a "requirement" of VM, it IS Virtual Memory. You cannot enable VM without paging.

PS. don't lump Demand Paging in with the Swapfile either...;)

@Peter Flass How about this?

Seems very reasonable imo. Most logical comment I've seen so far. :) — Preceding unsigned comment added by 115.188.27.65 (talk) 22:19, 27 August 2017 (UTC)

Segmented unpaged virtual memory usually means that 1) addresses are composed of a segment number and an offset within the segment, 2) the segment number is used to look up a segment descriptor that has a "present" bit, 3) if a reference is made to a segment whose segment descriptor does not have the "present" bit set, a fault is taken, 4) if a reference is made to a segment whose segment descriptor does have the "present" bit set, the segment descriptor gives the physical address of the beginning of the segment and the length of the segment, and if the segment offset is less than the length, it's added to the physical address of the beginning of the segment to give the physical address being referenced (if the offset is greater than the length, a fault is taken), 5) the operating system doesn't require all segments in a process's address space to be present in order for the process to be runnable, and 6) if a "segment not present" fault is taken, the OS finds space in memory large enough to hold the entire segment (removing clean segments from memory, pushing dirty segments to secondary storage and removing them from memory, and possibly shuffling segments in memory, if necessary), reads in the segment from secondary storage, points to its physical location in its segment descriptor and marking it as present, and returning from the fault to re-execute the faulting instruction.

This is what the 80286 offered. There were probably some older minicomputers and mainframes that offered it but didn't provide paging; the iAPX 432 might have offered it, although its model might have been more like the Burroughs model (see below), and the version of the Intel i960 used in the BiiN systems (and later sold as the 960 MX) offered it, with both non-paged and paged objects, as I remember.

(With the Burroughs large systems, I don't think you have something that looks like an "address space" - operands are referred to via "descriptors", which are like segment table entries, but they are ordinary operands, visible to non-privileged code, but not modifiable by non-privileged code. Earlier Burroughs machines didn't do paging; later ones allowed paged "segments"/operands, e.g. large arrays.)

On the B5000, B6500 and B6700 a process with its associated program reference table (PRT) looks like an address space and the program refers to operands via various forms of relative addressing and literals. On the B6500 et al the Saguaro stack looks like an address space and the program refers to operands via address couples and literals. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:42, 30 August 2017 (UTC)

( comment from Guy Harris (talk) 00:15, 28 August 2017 (UTC) continues ...)

That's VM without paging, but with segment swapping.

Segmented paged virtual memory usually means something similar to segmented paged virtual memory, except that the segment descriptor might, for example, contain the physical address of a page table, and the segment offset is used to look up a page table entry in the segment's page table, giving the physical address of the page containing the first memory location pointed to by the address, which is added to the offset-within-page part of the segment offset to give the physical address. Page table entries also have a "present" bit, and if it's not set, you get a page fault, serviced in the usual fashion. What the OS does with a segment-not-present fault depends on the OS.

Multics offered that (all segments were either paged or completely wired down into memory), as did the aforementioned BiiN systems. I don't remember whether Multics would ever just swap out all pages of a paged segment, and mark the segment as not present.

On x86, however, segmented paged virtual memory means that the base address in the segment descriptor is an address in linear paged virtual memory, and the segment offset is added to the base address (as with segmented unpaged virtual memory) and the result of that is used to look up a page table entry in the current page table.

So, yes, you can do VM without paging, in the sense of "moving pages, which have a fixed number of allowed sizes, and have addresses/offsets aligned on a boundary equal to the size of the page, to and from secondary storage". You can move variable-sized segments, instead. Paging "won", in the sense that most systems do paging without segmentation, and most systems with segmentation paged most or all segments, but System V/286 might have done segment swapping.

(I say "secondary storage" rather than "pagefile"; even for anonymous pages, where you haven't just mapped a file, or portion of a file, into your address space, with pages in that region of the address space moved to or from the file in question, the backing store might be a file, or a set of files, or a partition on a hard drive or solid state drive, or a file on a file server.) Guy Harris (talk) 00:15, 28 August 2017 (UTC) (Yes, that's my real name. No, I have never worked for Microsoft or Intel. No, I have never written any part of a "Windows Internals" book; my only involvement with those books is that I've bought some.)

As others have said, It is possible to use Virtual Memory without paging. It is even possible to use swapping (refereed often as "paging") without paging. 80386 in 32-bit protected mode segmentation can be used for this. The linear addresses ("effective address") obtained for accesses and code execution, are termed "virtual address". And if paging is disabled, are in fact physical addresses (they bypass TLB and paging machinery completely). 386 does provide ways to change segments, as well mark segments as present and/or accessed (modified), and OS could implement swapping using these techniques, by using these bits in GDT/LDT (and probably IDT, but the last one would be tricky). The segments doesn't need to be "page sized" either. This technique could also be used to share some data and code between processes or threads. The issue with using segmentation for swapping, is that there is no easy way to remove the segment and change it with something new, and continue execution of the program. This is because the base address of the segment would need to be the same as before, to be of any use. So only option would be to change the segment size (that is swap out the upper part of the segment), and restore it back (or enlarge sufficiently) on fault. Or pause the process completely, until it is restored. While this could be all possible, and could provide some level of paging, or support for multitasking with all process having access to more memory than there is on the system, it can't solve all the issues (i.e. one process can't use more memory than there is in a system, unless process code is written to deal with it explicitly somehow; and it is wasteful / non-granular because in majority of cases parts of a segment can't be swapped out, it is usually all or nothing). I don't know of any operating system ever, that used this technique, but I might be wrong. Maybe Windows 2.0? OS/2 1.x, and some versions of DR Concurrent DOS, Xenix probably used this technique too when running on 386. 81.6.34.185 (talk) 11:02, 12 January 2021 (UTC)

The Burroughs B5000 had segmentation but not paging, swapping entire segments as needed. Yes, that does lead to fragmentation, and MCP may need to relocate segments in order to compact real memory. Doing so would require adjusting the corresponding descriptors in each Program Reference Table (PRT)) referring to the relocated segments. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:23, 12 January 2021 (UTC)

In case anybody's unclear on why that's virtual memory, it means that not all segments used by a thread of control are required to be in physical memory in order for the thread of control to be runnable; if the thread of control refers to code or data in a segment that's not in physical memory, a fault will occur, and the fault handler will find physical memory into which that segment will fit and read that segment's contents from secondary store into that physical memory, removing other segments from physical memory if necessary (writing them to secondary store if the segment has been modified since the segment was last read into physical memory), adjust the descriptors as necessary, and then resume execution of the thread of control. — Preceding unsigned comment added by Guy Harris (talk • contribs) 18:51, 12 January 2021 (UTC)

Thrashing

As far as I know, thrashing requires neither paging nor page stealing in the form in which it's described in the paging article. It just requires that some form of demand loading be done (so that the entire address space of a process need not reside in main memory, with stuff loaded when it's referred to) and that not enough physical memory be available for the working sets of all processes considered "runnable" (so that trying to run process A could require that pages or segments from runnable process B be removed from memory, in order to load pages or segments from process A); that could presumably happen with segmentation if you demand-load segments. Guy Harris (talk) 19:55, 25 November 2013 (UTC)

Pageable versus swappable

A note on the last update to Virtual memory#Pinned pages: In IBM mainframe operating systems, e.g., z/OS, page fixing applies to individual pages and swapping refers to entire address spaces. A long term page fix does not render an address space unswappable, nor does making an address space un swappable cause page fixing. Thus an application can never be fixed, only unswappable.

Of course, a V=R application is both unswappable and pinned, but it is a rare special case; I'm not even sure whether it it is still supported. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:13, 29 May 2014 (UTC)

" page fixing applies to individual pages and swapping refers to entire address spaces. " This is the terminology used in VMS and Windows 8 as well, although some of the nuances are different. Also, (m) fixed spelling and formmating in previous Jeh (talk) 18:10, 29 May 2014 (UTC)

Paging vs RAM drive (See also)

• Paging: scheme by which a computer can store and retrieve data from secondary storage for use in primary storage
• RAM drive: block of primary storage that a computer's software uses as secondary storage

I think that, at least conceptually, paging is the opposite of RAM drive. So RAM drive should appear at least in "See also". --Edupedro (talk) 08:10, 21 July 2014 (UTC)

Let's have this discussion in one place. I have already answered at the RAM drive talk page. Thanks. Jeh (talk) 08:38, 21 July 2014 (UTC)

"Virtual storage"

IBM sometimes used different technical terms than others in the industry; for example, they used the term "Direct Access Storage Device", or DASD, to refer to all random-access devices (disks, drums, data cells), even after they stopped offering DASDs other than disks.

They also referred to main memory as "storage" rather than "memory", perhaps because they didn't want people to anthropomorphize it.

For what it's worth, a Google search for "virtual memory" on ibm.com got "About 11,100 results" and a Google search for "virtual storage" on ibm.com got "About 29,700 results". However, some of the latter results were for "storage" in the sense of "secondary storage", e.g. IBM Virtual Storage Center.

So "virtual storage" meaning "demand paging" is, these days, pretty much an IBM mainframe thing - unless you're running Linux on the IBM mainframe, in which case it's probably "virtual memory" as it is on every other Linux box on the planet. :-) Guy Harris (talk) 19:39, 16 October 2017 (UTC)

Not just IBM. See, e.g. http://www.dictionary.com/browse/virtual-storage, https://www.collinsdictionary.com/us/dictionary/english/virtual-storage, https://www.vocabulary.com/dictionary/virtual%20storage. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:48, 16 October 2017 (UTC)

I don't think we should present the terms as if they're equivalent. Although there may be a point regarding the unadorned words "memory" vs "storage", once "virtual storage" came to often refer to stuff that acts like secondary storage but is "virtual" in some way, its use to mean to "virtual memory" is much reduced. Jeh (talk) 22:11, 16 October 2017 (UTC)

None of those dictionaries give non-IBM sources, so this may be "IBM used it and, as a result, some dictionaries cite it, in addition to "virtual memory", as terms". Are there any vendors who used it (preferably not makers of S/370-compatible systems)? RCA called it "virtual memory" in the Spectra 70/46 manual.

Perhaps it's worth noting that IBM referred to it as "virtual storage" on System/3x0, but I'm unconvinced it deserves equal billing, especially given that IBM themselves use "virtual storage" when referring to (secondary) storage virtualization (and use "virtual memory" for AIX, for example, as per the Virtual Memory Manager on AIX). Guy Harris (talk) 22:35, 16 October 2017 (UTC)

While some may use "virtual storage" to mean virtualized main memory, I think it unlikely that there is signifcant usage of "virtual memory" to refer to virtualized secondary storage. Therefore the two terms should absolutely not receive equal credence, as they are not actually interchangeable. Jeh (talk) 05:08, 17 October 2017 (UTC)

My thinking was: 1. "virtual storage" disambiguates here. 2. The term was very extensively used in the IBM world. Maybe more recently it has come to mean "storage virtualization", which is the other article "virtual storage" disambiguates to, but the historical use should mean it be mentioned here. Peter Flass (talk) 06:33, 17 October 2017 (UTC)

1. Then the DA page should note that "virtual memory" and "virtual storage" are not really equivalent terms, that "virtual storage" more commonly (these days) refers to virtualized secondary storage. 2. The term "Virtual storage" could be mentioned here as e.g. "virtual memory (sometimes referred to as virtual storage)", perhaps with a footnote indicating that that term is also, less ambiguously, used to refer to virtualized secondary storage. Jeh (talk) 08:08, 17 October 2017 (UTC)

Tweaked slightly, how's that? Peter Flass (talk) 15:24, 17 October 2017 (UTC)

@GuyHarris:

"virtual storage" meaning "demand paging".

When did "Virtual Storage" become a synonym for "Demand Paging?"

@Jeh: Virtual storage" could be mentioned here as e.g. "virtual memory (sometimes referred to as virtual storage).

Virtual Memory is never "sometimes referred to as Virtual Storage" (unless erroneously).

Neither Demand Paging or Virtual Storage relate to Memory Management so why discuss? — Preceding unsigned comment added by

218.101.66.175 (talk) 20:06, 21 May 2023 (UTC)

When did "Virtual Storage" become a synonym for "Demand Paging?" When IBM used the term in that fashion.

Virtual Memory is never "sometimes referred to as Virtual Storage" (unless erroneously). IBM uses the term in the same sense as "virtual memory", at least with their mainframes, as they used the term "storage" instead of "memory" in other contexts, e.g. "main storage" rather than "main memory" and "real storage" rather than "real memory", although the ES/9000 series offered "improved support for increased real and virtual memory" (although the OS names have not been changed to speak of "Virtual Memory" rather than "Virtual Storage") and the latest line of mainframes have "redundant array(s) of independent memory"

Neither Demand Paging or Virtual Storage relate to Memory Management so why discuss? (Presumably you mean "why discuss here?") Because demand paging is a tool used to implement virtual memory (as is demand segment-swapping), and beause IBM used "storage" instead of "memory" in some contexts, including referring to "virtual storage" rather than "virtual memory" for System/370. Guy Harris (talk) 23:47, 21 May 2023 (UTC)

References

Prevalence, contraindications, side effects

Please address the questions of prevalence, and contraindications. Where is virtual memory used? where is it actually needed? where is it harmful? what side effects occur due to implementing virtual memory? and what side effects due to using it or not using it, on systems where it is already implemented?

If any of these questions are controversial, or if answers to them raise or have raised controversy, please address that too. If not, please explain why, as this would alarm me, if not any other being. — Preceding unsigned comment added by 150.101.157.18 (talk) 09:00, 14 October 2021 (UTC)

[My IP was added to this post despite my repeatedly expressing a wish that this not occur. Please whoever did that, justify your action, but do so elsewhere, prominently, loudly, and with consent of those involved. I do not wish my IP to be publicised, and I do not see why I should need to keep repeating myself on this matter. Are you rapists?] — Preceding unsigned comment added by 150.101.157.18 (talk) 09:04, 14 October 2021 (UTC)

You are way out of line. First, you added your IP address to your post by posting without first logging in. You don't have the right to use someone else's property to make anonymous posts unless the owner grants you that right.

Second, comparing adding a signature to rape is an inexcusable insult to the victims. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:57, 14 October 2021 (UTC)

Indeed. I've re-added the IP, as public attribution of an IP/username and a timestamp is ideally required on all talk page posts. Graham87 (talk) 07:30, 16 January 2024 (UTC)

Despite the kerfuffle over your signature, you raise a valid point, I'll take a look when I get a chance. Peter Flass (talk) 23:26, 12 February 2024 (UTC)

Samsung RAM Plus?

no RAM Plus (virtual memory on Samsung smartphones and tablets) in article 43.224.38.39 (talk) 06:26, 27 August 2024 (UTC)

No need for a special mention. It's just a marketing buzzword for paging in lieu of OOM killer.--Jasper Deng (talk) 06:41, 27 August 2024 (UTC)

Is checkerboarding a form of thrashing?

@Ian.joyner: In Virtual memory § Segmented virtual memory, you say that "A further problem to thrashing in using a segmented scheme is checkerboarding". Memory thrashing strikes me as the result of the short-term demand for memory being greater than the memory available to satisfy it, so that pages - or segments - likely to be used in the near future are removed from memory in order to handle a fault-in request, only to be evicted in the near future to satisfy a request for somethng recently removed from memory. Is the idea that external fragmentation of that sort reduces the amount of memory available to satisfy a request, making thrashing more likely, but that compacting a segment can make more memory available without having to evict something from memory? Guy Harris (talk) 07:12, 27 September 2024 (UTC)

Hello Guy. Thanks for the question. Perhaps my wording could be better, but I wanted to say that an extra problem with segmentation in addition to thrashing is checkerboarding, although the two are related, but distinct.

I thought of adding the fact that compaction is likely to be attempted to alleviate thrashing, but it was already getting rather long, and maybe what I wrote already suggests that.

Should we add something to that effect? But I fear it is already enough words. Ian.joyner (talk) 08:32, 27 September 2024 (UTC)