Well, no. Early timesharing systems that swapped out whole processes *did* call that swapping.eekee wrote:So when it was swapping, it wasn't called swapping? *ducks*bzt wrote:Actually no. The first time sharing systems "swapped" out entire processes. In DOS, there were a technique when you mapped in portions of code from disk when they were needed. Of course it wasn't called swapping back then, it was called overlays, and it was the app not the OS kernel that did the swapping, but the technique was essentially the same.eekee wrote:because doesn't swap require page tables anyway?Terminology is a crazy thing, isn't it?
First you had the systems running on hardware with no memory management at all, where there was only one userspace program in memory at a time, but the OS would write that program to disk and bring a new one in at every timeslice (which worked because timeslices were coarser and program sizes smaller than these days).
Then you had hardware with larger memory and segmented memory management, where each program got assigned one segment (or several), and the OS would still swap out entire programs, but only under memory pressure, not on every timestep.
Both of these were called swapping.
From there, you got to systems with paged memory management, which allowed just part of a process to be swapped out at a time, instead of the whole thing. Actually, segmented systems with multiple segments per program could do this too, but generally with less granularity and less flexibility about what you could actually do, depending somewhat on the exact architecture (the PDP-11 was better than the 286 in this regard, but neither was as good as hardware with actual paging).
Paging hardware allowed for leaps and bounds in what swapping could be used for, and so swapping that took advantage of this came to be called "paging".
The boundaries between these different stages were a bit fuzzy. One reason was that some systems had features that could be considered intermediate between two stages. 8086 segmentation, for example, expanded the address space and provided for easy relocation of code, but had no provision for protected memory, so it couldn't be used to trigger swap-in when an attempt was made to access a segment, so the 8086 fell more into the "no memory management" camp than the "segmented memory management" camp. The PDP-11s with memory management had a segmented memory management scheme with 8 segments per address space, so it was almost a paging system.
Another reason the boundaries were fuzzy is that the different form factors reached these stages at different times. Mainframes got to paged memory management while minicomputers were still in their infancy, and minicomputers were just getting to paged memory management as microcomputers took off. Furthermore, operating systems tended to lag the hardware somewhat: Unix/32v was the AT&T Vax port of Unix, but simply translated the memory management scheme Unix had used on the segmented PDP-11 to the paged Vax without actually making use of any of the new features that paging made available. And while robust paged operating systems for microcomputers appeared within a few years of paged hardware (NT, OS/2, Linux), Mac OS never transitioned away from being a single-address-space system until they transitioned to Unix with OS X, and while Windows did better, consumer versions of Windows still had core components that treated the system as one without memory management right up until XP came out (which was why Win16 and Win9x had a reputation for being burning piles of unstable manure).
Across *all* of these stages, at various times, there has been the concept of overlays. Overlays are the same *idea* as swapping, but they are distinguished from it in that overlays are managed by the application, not the OS (though the OS may contain facilities to assist applications in the use of overlays).
On very early systems with no memory management, or only segmented memory management, where the amount of memory available to applications tended to be limited by the actual amount of physical RAM available, programs used overlays to deal with working sets that did not fit in RAM.
Later on, even into the present day, on machines with more physical RAM than address space, or on paged systems where swap can be used to provide more backing store than the available address space, programs use overlays to deal with working sets larger than the address space. In this case, overlay data that has been "swapped" out of a process's address space may very well still be in RAM, just unmapped from the process's address space so that something else can be mapped in at the same address.
Many early microcomputers had only 64k of address space, so if the system had more than 64k of RAM, not all of it could be connected to the CPU at once, and in practice the limit was less than 64k because large portions of the address space were taken up by ROMs for system firmware or by things like video memory that couldn't be used arbitrarily. So these systems needed bank switching hardware to deal with large amounts of RAM, and programs needed to arrange themselves and their data into overlays that could be bank-switched out to allow other overlays, or ROMs, or video memory, etc, to be switched in.
The PC had a larger address space (1 megabyte, of which 640k was available freely to programs), so it took longer to run up against this, but when PC's started shipping with megabytes of memory, "expanded memory" was introduced, where an expansion card would bank switch a 64k window above the 640k line, which programs could use for overlays. A problem with this was that the memory on the bank switching cards was generally not mappable above 1M when a 286 CPU was operating in protected mode, so separate memory was needed for that. There was some software available that used the same ABI as the firmware on the expanded memory cards and swapped the expanded memory window to disk rather than bank switching in RAM, which gave the same effect with a performance penalty. When the 386 came out, though, the paging features of the 386 allowed emulating an expanded memory board in software at no performance cost (because a CPU with a paged MMU effectively *is* an expanded memory board, with the added benefits of being finer-grained, and allowing any page of memory to be bank switched to any page-aligned address).
On segmented-memory minicomputers with constricted address spaces, like the memory-managed variants of the PDP-11, programs didn't have to share their address space with ROMs or device drivers (on the PDP-11, not even with the kernel, as it had its own set of segment registers and its own address space), but if they ran beyond the available address space, the OS often provided facilities for a program to request that a given module be unloaded and another loaded to the same address.
More recently, I've heard that 32-bit PAE versions of Windows include overlay system calls for programs that need more than 4 GiB, though that was mostly needed for servers and the 32/64-bit transition has been pretty much complete in that space for a while (even for consumer PCs it's mostly over, with Linux distributions starting to drop their 32-bit variants).
Even without OS support, however, overlays could be implemented by the application itself on a modern system by using something analogous to the combination of memfd_create() and mmap() on Linux (or even just mmaping files on disk, depending on the level of security from interference from other programs needed).
In summary, the difference between "swapping", "paging" and "overlays" is:
"Swapping" refers to the OS writing programs, or parts of programs out to disk in a manner that is transparent to the program involved except insofar as it affects timing (and insofar as access to the system clock is provided to programs, which has generally been the case historically, but may need to be reconsidered in the future for programs that don't absolutely need it to mitigate Specter/Meltdown type timing attacks). It can be used to refer to any such process, but the word is often used to designate non-paged swapping in contexts where paged and non-paged swapping are differentiated.
"Paging" refers to hardware features that provide fine-grained, whole-memory bank switching, generally with accompanying memory protection mechanisms. It also refers to operating systems making use of those features to isolate programs from each other, provide programs with a view of their address space that is independent from their location in physical memory, allow programs to share memory, swap data to disk when under memory pressure etc. It is furthermore used more narrowly to refer to specifically to paged swapping, sometimes as part of the concept of demand paging, wherein swapping occurs strictly in page-at-a-time increments, and files are generally not loaded into memory all at once, but just recorded to be mapped to a certain address in a process's address space and pulled in a page at a time when and if the program attempts to access each page.
"Overlays" are, basically, application-driven swapping. Unlike swapping proper, they are *not* transparent to the application, the application has to explicitly request that the OS flip overlays (or manipulate the hardware to flip overlays on MMU-less systems, or munmap the current overlay and mmap the new one on memory managed OSes with no direct support for overlays). If it doesn't it will access the overlay currently loaded at the address in question rather than the one it wants to access, whereas with swapping, what the application sees as loaded at a given address doesn't change; it's just that the application may be swapped out and not runnning, or the OS may need to fetch the data the application is attempting to access before allowing the application to continue.
how about the VMS name, what it meant? i wasn't there, but i heard, when this mechanism appeared, it was named "virtual memory". nowhere outside x86 it's refered as "paging". the emphasis that it's a "paging" mechanism makes no sense say on ARM - there is always one mechanism and nothing else, the memory is seen as a space of pages/frames both "physical" and "virtual", and the mapping (virtual memory system) is established between these only entities; there is no need to emphasize it's paging or framing or whatever, as there is nothing else, whereas x86 has yet segments, so it's either flat "paging" mapping or not so flat and "generally speaking" - oversofisticated "segmentation". basically that "paging enabled" means "oh, you don't want to use segments and want those "pages", here you go" and only there this term makes sense. on others, you just turn on MMU and configure stuff, you don't choose whether VM will be organized as "paged" or as "not exactly paged". yes, i am aware about mips kseg0/kseg1, but it's another story.
