Linux memory usage and page buffer)

SELF: http://blog.csdn.net/eroswang/article/details/4131034

Linux can be considered as a resource managementProgramWhile other applications run on it, Linux manages the application memory allocation, recovery, and so on. For management, it first needs to allocate static memory space to itself:CodeSegment space, mem_map [] space, and so on. Then it dynamically manages the remaining Ram using the buddy system.

The Linux kernel's pagetable swapper_pg_dir will be the virtual address 0xc0000000 ~ 0xc0000000 + 896m ing to physical address 0x0 ~ 0x896 m. Except for the ram occupied by kernel code, the remaining physical Ram is idle. When the kernel is required, it can be used directly after allocation, without modifying swapper_pg_dir. When the user space is needed, the kernel allocates a page for it and modifies the pagetable of the application process to map the allocated page to the corresponding application process address space. The kernel does not need to be mapped again because swapper_pg_dir has mapped the 896m address to the kernel. Unless the kernel uses high_mem, it is necessary to re-map the high 128 MB space of the kernel (modify swapper_pg_dir's high items ).As you can see above, as long as the page allocated by the application process is less than 896 MB (within the kernel address space), the kernel can be accessed directly (see # DEFINE _ copy_user (to, from, size) here, "to" is the kernel address and uses the 768 ~ of page_dir ~ 896 Items (3g ~ 3G + 896m kernel space), from uses the user address: 0 ~ of page_dir ~ 767 Items (0 ~ 3g-1 user address space )). If the page of an application process is larger than 128 MB, the kernel cannot be accessed directly. You need to map the address space of the application process using the high items of swapper_pg_dir, which is also the reason for the existence of high_mem.

RAM usage
1. Static usage: used for Linux code, data structure, and other Ram, which does not need to be managed.
2. Dynamic use:Managed by buddy. When the page applied through buddy is not used, it is not immediately released to Buddy. Instead, it is cached in the form of 3 (1) managed by Slab (2)Page boxes managed by two-way linked lists (active_list and inactive_list)(3) inode and dentry are cached by icache and dcache. In this way, when the system recycles the page, the page is also released to buddy through these three aspects. The reason for this is that distribution or release to buddy through buddy may need to split large blocks or merge small blocks to large buddy, which is time-consuming. Therefore, cache allocated pages as much as possible. (It seems that Linux is especially fond of such buffering, which brings Asynchronization to the system. In general, Asynchronization is more efficient: A cache is equivalent to a stream, which can certainly improve efficiency)

This is because Buddy Management generates a large number of internal fragments and slab is used to reduce fragments. Generally, slab is object-based, so it is not in the unit of page boxes, so it is not easy to switch in and out in the unit of pages. A two-way linked list is used to concatenate the currently used page boxes in the system to facilitate scanning and to swap out (recycle) the page boxes ). Therefore, when the system needs to recycle the page box, it needs to be recycled from three aspects: slab, two-way linked list, And inode dentry.

The page boxes in a two-way linked list can be divided into two usage cases: 1. page boxes with backup files (such as page buffer and MMAP); 2. page box without backup files (application code segment, data segment, stack segment etc ). For 2, because there is no backup file, you need to open a swap file on the disk to store the page box without backup files. In this way, backup files are available for both 2 and 2. With the backup file, you need to manage the page boxes of different files in a Data Structure: address_space. For page boxes with backup files, use the address_space specific to each file. For page boxes without backup files, use the address_space: swapper_space public in the system. in this way, 1 and 2 are unified.

To deal with disks, the system must first allocate a page Buffer: When you need to read a file, first query address_space to see if page_buffer already exists. If not, allocate a page buffer page box, insert address_space. When writing out a disk, you also need to check whether there is page buffer in address_space. If not, allocate a page buffer page box and insert address_space. Then, the content to be written to the page buffer and returned (the page buffer will be refreshed to the disk by the page recycle daemon thread ). The above operations also apply to scenarios where no backup files are available (only the address_space they use is swapper_space ).

Page buffer is the visible (used) facility of VFS, while cache buffer is the facility used by block drivers, A page buffer contains multiple cache buffers (the cache buffer must also be used by Block devices ). That is to say, VFS and other upper layers can "see" pages, while the lower-layer block device drivers can only see blocks. Therefore, when VFS writes a page to a block device, it must first divide the page into several buffers, and each buffer is described using buffer_head. The buffer_head in a page is connected using a single-connection table, only the devices at the underlying layer can be recognized.