Memory management of Linux data summary

There are a lot of jealous articles on the Internet, which misleads many people. Many people misunderstand Linux. It may come from these widely circulated technical articles. Below we introduce a series to summarize. Start with memory management.

Compact_memory

Common text on the web:

Compact_memory

Only valid if the CONFIG_COMPACTION option is enabled. When writing 1 to the file (/proc/sys/vm/compact_memory), all memory fields are compressed, making the free memory as contiguous as possible.

When the kernel compilation parameter sets CONFIG_COMPACTION, there will be an entry file in /proc/sys/vm/compact_memory. Writing 1 to this file will compress all the zones so that contiguous blocks of memory can be provided as much as possible. This feature is very important when you need to allocate large pages, but the process will directly perform compact memory when needed.

Correction

The compact here has no semi-finance relationship with "compress", which is a memory migration technology that makes free memory more compact. The effect achieved is as follows:

Suppose red and white are free and occupied pages, respectively. The state before the memory compaction is:

Then the compact behavior of the memory can achieve the following purposes, free memory is piled up, so if you want to apply for more contiguous memory, you can satisfy:

If you want to translate literally, compact memory can be translated as "memory compact." But it is definitely not compression, because zRAM and the like are using compression technology.

2. The difference between cached and buffers

Common text on the web:

Buffers and cachedå•¥ difference

A buffer is something that has yet to be "written" to disk.

A cache is something that has been "read" from the disk and stored for later use

For applications, buffers/cached is equal to usable, because buffer/cached is for improving file read performance. When the application needs to use memory, buffer/cached will be quickly reclaimed.

So from the application point of view, available memory = system free memory + buffers + cached.

Correction

It is very easy to misunderstand here, thinking that the buffers in the free command are generated for writing, and cached is generated for reading.

In reality, cached and buffers have no semi-finance relationship with reading and writing. They are all cached. The only difference is that if you cat /dev/sda1 > /dev/null, then /dev/sda1 content enters buffers, if you Cat /mnt/aaa/bbb.c > /dev/null, the contents of /mnt/aaa/bbb.c enter cached. Therefore, these two caches, one with the raw device or partition as the background, one with the files in the file system as the background, regardless of reading and writing.

Buffers mainly have 2 users:

Application direct access to raw partitions

The implementation of the file system itself will think that /dev/sda1 is a raw device, so the file system's metadata will be cached to buffers.

3. PSS

Many people quote this explanation about pss:

Https://yq.aliyun.com/articles/24048

Correction

This document has 3 questions:

The part shared by the two processes is far from the shared library. For example, if we open two bash processes in Linux, then these two bashes actually share one code segment; other mmap() is the shared mapping. Also.

The memory in the shared library is not shared, only the memory that does not do CoW (copy-on-write) will be shared across processes.

The USS removes all memory shared across processes, not just the shared library.

The 4 pieces of memory in the above figure are the part of the libc code segment that resides in memory and are shared by 3 processes. 5 This memory is the code segment of bash, which is pointed to by 2 processes (1044 and 1045). These need to be scaled when calculating PSS.