Virtual Memory: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
pc>Yuron No edit summary |
||
Line 3: | Line 3: | ||
-->{{#invoke:Dependencies|add|Memory Mapping,5|Memory Protection,5|Virtualisation,4|Concepts,4}} | -->{{#invoke:Dependencies|add|Memory Mapping,5|Memory Protection,5|Virtualisation,4|Concepts,4}} | ||
<blockquote> | <blockquote> | ||
This is an overview: you may need to explore some constituent parts | This is an overview: you may need to explore some constituent parts before it becomes completely clear. | ||
before it becomes completely clear. | |||
</blockquote> | </blockquote> | ||
One of the most important functions of an operating system is to | One of the most important functions of an operating system is to provide an abstracted [[Virtualisation|<em>virtual</em>]] environment for applications code. An application has an idealised view of the machine (<em>any</em> machine) it is running on. A major consideration is the <strong>address space</strong> of the system. | ||
provide an abstracted [[Virtualisation|<em>virtual</em>]] environment for | |||
applications code. An application has an idealised view of the | |||
machine (<em>any</em> machine) it is running on. A major consideration is | |||
the <strong>address space</strong> of the system. | |||
Different machines may have different amounts of <em>physical</em> memory | Different machines may have different amounts of <em>physical</em> memory installed: it depends on what you pay for. However, in a virtual memory system the application can simply assume that ’all’ the memory – the amount being set by the virtual machine size – is present and it can use any which it wants. This is also independent of other applications which may be running concurrently – which can also use any address they want, including those which conflict. | ||
installed: it depends on what you pay for. However, in a virtual | |||
memory system the application can simply assume that ’all’ | |||
the memory – the amount being set by the virtual machine size – is | |||
present and it can use any which it wants. This is also independent | |||
of other applications which may be running concurrently – which can | |||
also use any address they want, including those which conflict. | |||
To achieve this, each [[Processes|process]] has a private map which | To achieve this, each [[Processes|process]] has a private map which translates the <strong>virtual addresses</strong> (the ones the application generates) into non-conflicting <strong>physical addresses</strong>. This solves any potential address address conflicts. Any application only knows its own virtual addresses; the physical addresses are only known only | ||
translates the <strong>virtual addresses</strong> (the ones the application | |||
generates) into non-conflicting <strong>physical addresses</strong>. This solves | |||
any potential address address conflicts. Any application only knows | |||
its own virtual addresses; the physical addresses are only known only | |||
within the O.S. | within the O.S. | ||
Line 30: | Line 15: | ||
=== Benefits === | === Benefits === | ||
It must first be noted that the amount of memory available has followed ’[https://en.wikipedia.org/wiki/Moore%27s_law Moore’s Law]’ and that the | It must first be noted that the amount of memory available has followed ’[https://en.wikipedia.org/wiki/Moore%27s_law Moore’s Law]’ and that the (virtual) address space of popular processors has had to mirror that. For general convenience (and, somewhat, by convention) although memory sizes double or quadruple in each process generation, architectures have doubled the number of bits, thus progressed in fewer, bigger steps. | ||
(virtual) address space of popular processors has had to mirror that. For general convenience (and, somewhat, by convention) although memory sizes double or quadruple in each process generation, architectures have doubled the number of bits, thus progressed in fewer, bigger steps. | |||
The first really widespread microprocessors were “8-bit” (which, typically used 16-bit addresses); the next generation were “16-bit” (address sizes being expanded by [[Extra:Intel_x86_Segmentation|various stratagems]] to 20- or 24-bits); thence to “32-bit” machines (addresses are/were often also 32-bits) and currently to “64-bit” processors (addresses may be <em>reduced</em> to (say) 56 bits). | The first really widespread microprocessors were “8-bit” (which, typically used 16-bit addresses); the next generation were “16-bit” (address sizes being expanded by [[Extra:Intel_x86_Segmentation|various stratagems]] to 20- or 24-bits); thence to “32-bit” machines (addresses are/were often also 32-bits) and currently to “64-bit” processors (addresses may be <em>reduced</em> to (say) 56 bits). | ||
Line 40: | Line 24: | ||
<blockquote> | <blockquote> | ||
==== Observations ==== | ==== Observations ==== | ||
*Very few processes use the whole of their virtual address space.<br /> | *Very few processes use the whole of their virtual address space.<br /> | ||
*It may be hard to predict <em>which</em> virtual addresses a given process chooses to use.<br /> | *It may be hard to predict <em>which</em> virtual addresses a given process chooses to use.<br /> | ||
Line 48: | Line 31: | ||
=== Swapping === | === Swapping === | ||
Mapping the memory works okay providing that the sum of the memory | Mapping the memory works okay providing that the sum of the memory used by all current applications does not exceed the size of the installed physical memory. If that happens then some more storage needs to be found: the solution is to use some <em>secondary</em> storage which is likely to be a [[Disks|magnetic <strong>disk</strong>]]. | ||
used by all current applications does not exceed the size of the | |||
installed physical memory. If that happens then some more storage | |||
needs to be found: the solution is to use some <em>secondary</em> storage | |||
which is likely to be a [[Disks|magnetic <strong>disk</strong>]]. | |||
If the demand on the physical store becomes too great, some [[Memory_Pages|pages]] are copied onto disk to free up some new space. The pages are chosen by (inspired) guesswork as to which will probably not be needed in the near future by a [[Page_Eviction|scheduling algorithm]]; this is the same <em>principle</em> as | If the demand on the physical store becomes too great, some [[Memory_Pages|pages]] are copied onto disk to free up some new space. The pages are chosen by (inspired) guesswork as to which will probably not be needed in the near future by a [[Page_Eviction|scheduling algorithm]]; this is the same <em>principle</em> as [[caching]]. The process is usually referred to as “[[Paging|<strong>paging</strong>]]” or “<strong>swapping</strong>”. | ||
[[caching]]. The process is usually referred to as “[[Paging|<strong>paging</strong>]]” or “<strong>swapping</strong>”. | |||
[[Image:VM_paging.png|link=|alt=Paging]] | [[Image:VM_paging.png|link=|alt=Paging]] | ||
Line 67: | Line 45: | ||
Answer: with a combination of hardware and (operating system) software. | Answer: with a combination of hardware and (operating system) software. | ||
This is explained across various articles; the <strong>key concepts</strong> are | This is explained across various articles; the <strong>key concepts</strong> are probably: | ||
probably: | |||
*[[Memory_Mapping|Memory mapping]] keeps the application code supplied with memory. | *[[Memory_Mapping|Memory mapping]] keeps the application code supplied with memory. | ||
Line 75: | Line 52: | ||
*[[Paging]] supports swapping to disk. | *[[Paging]] supports swapping to disk. | ||
[https://www.youtube.com/watch?v=2quKyPnUShQ Video] (12 mins.) on | [https://www.youtube.com/watch?v=2quKyPnUShQ Video] (12 mins.) on virtual (or, possibly, “virutal”!) memory. | ||
virtual (or, possibly, “virutal”!) memory. | |||
<!-- Quite a decent explanation --> | <!-- Quite a decent explanation --> | ||
---- | ---- | ||
=== Memory sizes === | === Memory sizes === | ||
The extent of the <strong>virtual address space</strong> is set by the hardware | The extent of the <strong>virtual address space</strong> is set by the hardware architecture of the machine: a “64-bit” machine can address 2<sup>64</sup> bytes. This is what the programmer sees. | ||
architecture of the machine: a “64-bit” machine can | |||
address 2<sup>64</sup> bytes. | |||
This is what the programmer sees. | |||
The extent of the <strong>physical address space</strong> is fixed in hardware and | The extent of the <strong>physical address space</strong> is fixed in hardware and is often (but does not have to be) the same size as the virtual address space. | ||
is often (but does not have to be) the same size as the virtual | |||
address space. | |||
<blockquote> | <blockquote> | ||
Contemporary x86-64 system ’only’ support a 48-bit | Contemporary x86-64 system ’only’ support a 48-bit physical address (256 TiB), for example. | ||
physical address (256 TiB), for example. | |||
</blockquote> | </blockquote> | ||
The amount of <strong>physical RAM</strong> is anything up to the supported address | The amount of <strong>physical RAM</strong> is anything up to the supported address space, subject to limitations of cost, power/cooling and room in the machine. | ||
space, subject to limitations of cost, power/cooling and room in the | |||
machine. | |||
---- | ---- | ||
{{BookChapter|10|389-440}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Virtual Memory}} | {{Category|Virtual Memory}} | ||
{{Category|Concepts}} | {{Category|Concepts}} | ||
{{Category|Memory}} | {{Category|Memory}} |
Revision as of 14:39, 4 August 2019
On path: Memory | 1: Memory • 2: Memory Management • 3: Memory Sizes • 4: Memory Mapping • 5: Memory Segmentation • 6: Memory Protection • 7: Virtual Memory • 8: Paging • 9: Memory Management Unit (MMU) • 10: Caching • 11: Cache • 12: Translation Look-aside Buffer (TLB) |
---|
Depends on | Memory Mapping • Memory Protection • Virtualisation • Concepts |
---|
This is an overview: you may need to explore some constituent parts before it becomes completely clear.
One of the most important functions of an operating system is to provide an abstracted virtual environment for applications code. An application has an idealised view of the machine (any machine) it is running on. A major consideration is the address space of the system.
Different machines may have different amounts of physical memory installed: it depends on what you pay for. However, in a virtual memory system the application can simply assume that ’all’ the memory – the amount being set by the virtual machine size – is present and it can use any which it wants. This is also independent of other applications which may be running concurrently – which can also use any address they want, including those which conflict.
To achieve this, each process has a private map which translates the virtual addresses (the ones the application generates) into non-conflicting physical addresses. This solves any potential address address conflicts. Any application only knows its own virtual addresses; the physical addresses are only known only within the O.S.
Benefits
It must first be noted that the amount of memory available has followed ’Moore’s Law’ and that the (virtual) address space of popular processors has had to mirror that. For general convenience (and, somewhat, by convention) although memory sizes double or quadruple in each process generation, architectures have doubled the number of bits, thus progressed in fewer, bigger steps.
The first really widespread microprocessors were “8-bit” (which, typically used 16-bit addresses); the next generation were “16-bit” (address sizes being expanded by various stratagems to 20- or 24-bits); thence to “32-bit” machines (addresses are/were often also 32-bits) and currently to “64-bit” processors (addresses may be reduced to (say) 56 bits).
- Early in a processor generation it is infeasible to fill the available address space with physical memory (even for a single process). Virtual memory allows the physical memory to appear in the places it is wanted.
- Late in a processor generation there may be more physical memory than fits in the address space. Virtual memory allows the physical memory to be used sensibly to support multiple processes without needing to ’swap’ (see below).
Observations
- Very few processes use the whole of their virtual address space.
- It may be hard to predict which virtual addresses a given process chooses to use.
- There is, typically, significant locality of access: if one address is used it is likely that addresses around it are also used.
Examples: instructions in a program; stack data; objects … These properties are therefore exploited when memory mapping virtual to physical addresses, a process usually called “address translation”.
Swapping
Mapping the memory works okay providing that the sum of the memory used by all current applications does not exceed the size of the installed physical memory. If that happens then some more storage needs to be found: the solution is to use some secondary storage which is likely to be a magnetic disk.
If the demand on the physical store becomes too great, some pages are copied onto disk to free up some new space. The pages are chosen by (inspired) guesswork as to which will probably not be needed in the near future by a scheduling algorithm; this is the same principle as caching. The process is usually referred to as “paging” or “swapping”.
Swapping keeps everything running but each swap is time-consuming, so as swapping increases the applications (i.e. “the computer”) will slow down. You will probably have witnessed this. Buying more (electronic) memory (RAM) will delay the point where extensive swapping becomes necessary – hence a ’faster’ machine if you want to run lots of applications or memory-hungry applications.
Sounds familiar?
How is it done?
Answer: with a combination of hardware and (operating system) software.
This is explained across various articles; the key concepts are probably:
- Memory mapping keeps the application code supplied with memory.
- Memory protection keeps the applications secure and separated.
- The MMU is the hardware which implements all this.
- Paging supports swapping to disk.
Video (12 mins.) on virtual (or, possibly, “virutal”!) memory.
Memory sizes
The extent of the virtual address space is set by the hardware architecture of the machine: a “64-bit” machine can address 264 bytes. This is what the programmer sees.
The extent of the physical address space is fixed in hardware and is often (but does not have to be) the same size as the virtual address space.
Contemporary x86-64 system ’only’ support a 48-bit physical address (256 TiB), for example.
The amount of physical RAM is anything up to the supported address space, subject to limitations of cost, power/cooling and room in the machine.
Also refer to: | Operating System Concepts, 10th Edition: Chapter 10, pages 389-440 |
---|