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)

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)

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)

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)