Address: http://blog.csdn.net/newjerryj/article/details/4616819
In the view of hardware engineers and common users, memory is the memory stick inserted or solidified on the motherboard. They have a certain capacity, for example, 64 MB. But in the eyes of application programmers, they don't care too much about the memory size inserted on the motherboard, but the memory space they can use-they can develop a program that needs to occupy 1 GB of memory, and let it run on the OS platform, even if this running host only has 128 MB of physical memory. For OS developers, there is a gap between the two. They both need to know the details of the physical memory and also need to provide a mechanism to provide another memory space for application programmers, the size of the memory space does not have any relationship with the actual physical memory size.
We define the memory space provided by the physical memory stick on the motherboard as physical memory space, and the memory space seen by application programmers as linear space. The physical memory size can be different on different hosts. The physical memory size inserted on the motherboard varies with the physical memory size. However, the linear space provided for application programmers is fixed, it does not change with the physical memory, so as to ensure the portability of applications. Although the size of the physical memory can affect the performance of the application program running, and in many cases there is a minimum requirement on the size of the physical memory, these factors are only for the normal operation of an OS.
The size of the linear space is fixed to 4 GB on the 32-bit platform, which is true for every process (an application can be a multi-process, in the eyes of the OS, in process units ). In other words, linear space is not shared by processes, but isolated by processes. Each process has a 4 GB linear space of the same size. A process's access to a memory address never conflicts with other processes's access to the same memory address. For example, a process can read an integer 8 from the linear space address 1234abcdh, while another process can read an integer 20 from the linear space address 1234abcdh, depending on the process's own logic.
At any time, only one process is running on one CPU. So for this CPU, at this moment, the entire system has only one linear space, which is oriented to this process. When a process is switched, the linear space also changes. Therefore, the conclusion is that each process has its own linear space, and its linear space is known only when the process is running. At other times, its linear space is unknown to the CPU. Therefore, although each process can have a 4 GB linear space, there is only one linear space in the eyes of the CPU. Linear Space changes with process switching.
Although there is no relationship between the size of the linear space and the size of the physical memory, applications using the linear space will eventually run in the physical memory. Any linear address provided by the application must be converted to a physical address to truly access the physical memory. Therefore, the linear memory space must be mapped to the physical memory space. This ing relationship needs to be established by using the data structure specified by the hardware architecture. We may call it a ing table first. The content of a ing table is the ing between a linear memory space and a physical memory space. Once the OS Kernel tells a CPU the location of a ing table, the CPU needs to access a linear space address based on the content of the ing table, this linear space address is converted into a physical space address and sent to the address line. After all, the address line only knows the physical address.
Therefore, we can easily draw a conclusion that if we give different ing tables, the physical addresses that the CPU converts to a certain level-1 space address will also be different. Therefore, we create a ing table for each process to map the linear space of each process to the physical space as needed. Since only one application can be running on a certain CPU at a time, when the task is switched, replace the ing table with the response ing table so that each process has its own linear space without affecting each other. Therefore, at any time, a CPU only needs a ing table to convert the linear space of the current process to the physical space.
--------------------------------------------------------------------------------
2. OS kernel space & process space
Because the OS kernel must exist in the memory at any time, but the process can be switched, there are two parts in the memory at any time, OS kernel and user process. At any time, there is only one linear space for a CPU. Therefore, this linear space must be divided into two parts, one for the OS kernel and the other for the user process. Since the OS Kernel occupies a portion of the linear space at any time, the linear space reserved for the OS kernel can be identical for the linear space of all processes, that is, their respective ing tables are also divided into two parts, one is the process private ing part, and the content of the OS Kernel ing part is identical.
In this sense, we can think that for all processes, they share the linear space occupied by the OS kernel, and each process has its own private linear space. If we divide any 4 GB linear space into 1 gb OS kernel space and 3 GB process space, the 1 gb OS kernel space in the 4 GB linear space of all processes is shared, while the remaining 3 GB process space is private to all processes. Linux does this, while Windows NT makes the OS kernel and process use 2 GB linear space each.
--------------------------------------------------------------------------------
3. segment mapping & page Mapping
Only when the content of all linear spaces is placed in the physical memory can they be truly run and operated. Therefore, although the OS kernel and processes are both placed in linear space, they must eventually be placed in physical memory. Therefore, the OS kernel and all processes eventually share the physical memory. At this stage, the physical memory is far smaller than the linear space-the linear space is 4 GB, and the physical memory space is usually only several hundred megabytes, or even smaller. In addition, even if the physical memory is 4 GB, each process can have 3 GB linear space (if the private linear space of the process is 3 GB ), it is obviously unrealistic to put the linear space of all processes in the physical memory. Therefore, the OS kernel must put some data or code that are temporarily unavailable to some processes out of the physical memory, and provide the limited memory to the most needed processes. In addition, the OS kernel may run at any time, so it is best to keep the OS kernel in the physical memory forever. We only exchange process data.
Ing from a linear space to a physical space requires a ing table. The ing table maps a linear space to a physical memory space of the same size. Theoretically, we can use two ing methods: variable-length ing and fixed-length ing. Variable-length ing refers to ing a variable-length segment to the physical memory according to different needs. The format can be as follows (Linear Space Segment start address, physical space segment start address, and segment length ). If a process has three segments: 10 m data segments, 5 m code segments, and 8 K stack segments, you can create three items in the ing table, each of which is for one segment. This seems no problem. However, if our actual memory is only 32 MB, of which 10 MB is occupied by the kernel and the physical space left for the process is only 22 MB, then when the process is running, it occupies 10 m + 5 m + 8 K of memory space. Then, when the process is switched, if another process has the same memory requirements, the remaining 22 m-(10 m + 5 m + 8 K) is obviously not enough, at this time, only some segments of the original process can be swapped out, and the entire segment must be swapped out. This means that we have to replace at least one 10 m data segment, and the cost is very high, because we have to copy the 10 m content to the disk, and the disk I/O is very slow.
Therefore, the result of using a variable-length field ing is that a segment is either completely swapped in or out. But in reality, not all code and data in a program can be accessed frequently, and often accessed only accounts for part of all code data, or even a small part. Therefore, a more effective strategy is to replace only those that are not frequently used and retain those that are frequently used. Instead of switching the entire segment. In this way, you can avoid large slow disk operations.
This is the fixed-length ing policy. We divide the memory space into fixed-length blocks, each of which is called a page. The basic format of the ing table is (the starting address of the physical space page). Because the page is fixed, you do not need to specify its length. In addition, we do not need to specify linear addresses in the ing table. We can use linear addresses as indexes to retrieve the corresponding physical addresses from the ing table. When using pages, the policy is as follows: when switching out pages, we only replace those inactive pages, that is, those that are not frequently used, and keep those active pages. During the conversion, only the pages requested for access are swapped in. pages not requested for access will never be swapped in to the physical memory. This is the core idea of the Request page algorithm.
This leads to a page size problem: First, we cannot take bytes as the unit, in this way, the size of the ing table is the same as that of the linear space. If the entire linear space is mapped, we cannot use all the linear space to store this ing table. As a result, we can also know that the smaller the page, the larger the capacity of the ing table. However, the ing table cannot occupy too much space. However, if the page is too large, it will face the same problem as the uncertain length field ing. Each time a page is swapped out, a large number of disk operations are required. In addition, since the minimum unit of memory allocated to a process is page, if our page size is 4 MB, even if a process only needs to use 4 kb of memory, it also has to occupy the entire 4 MB page, which is a big waste. Therefore, we must compromise between the two, the general platform of the page size is 1 kb to 8 KB, the page size specified by the IA-32 is 4 kb. (IA-32 also supports 4 MB pages, you can choose based on your OS usage, usually 4 kb pages ).