MemTotal:     16344972 kB
MemFree:      13634064 kB
MemAvailable: 14836172 kB
Buffers:          3656 kB
Cached:        1195708 kB
SwapCached:          0 kB
Active:         891636 kB
Inactive:      1077224 kB
HighTotal:    15597528 kB
HighFree:     13629632 kB
LowTotal:       747444 kB
LowFree:          4432 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:             968 kB
Writeback:           0 kB
AnonPages:      861800 kB
Mapped:         280372 kB
Shmem:             644 kB
Slab:           284364 kB
SReclaimable:   159856 kB
SUnreclaim:     124508 kB
PageTables:      24448 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:   7669796 kB
Committed_AS:   100056 kB
VmallocTotal:   112216 kB
VmallocUsed:       428 kB
VmallocChunk:   111088 kB
AnonHugePages:   49152 kB
ShmemHugePages:      0 kB
ShmemPmdMapped:      0 kB

MemTotal	总可用内存(物理内存减去几个保留比特位和内核二进制代码)	比物理内存总量少一点，因为linux内核自己也会占用一部分内存。
MemFree	LowFree + HighFree
MemAvailable	在没有交换的前提下，对新应用程序可用的内存的估计。根据MemFree、SReclaimable、file LRU lists的大小和low watermarks in each zone的计算。这个估计考虑了以下因素:系统需要一些页缓存才能正常工作，而且并非所有可回收的slab都是可回收的，因为有些slab正在使用。这些因素的影响因系统而异。
Buffers	表示内核缓冲区使用的内存量。缓冲区是内核用来存储用于块设备的输入输出操作的临时数据的内存区域。这些缓冲区对于提高系统的性能至关重要，因为它们可以减少对磁盘的直接访问次数，通过缓存常用数据来加速数据读写操作。 文件系统的元数据：比如目录信息、inode信息等，这些信息的缓存可以加快文件系统的访问速度。 块设备的I/O操作：对于读取或写入块设备（如硬盘、SSD等）的操作，Buffers可以暂存数据，使得连续的读写操作更加高效。	Buffers内存页同时也在LRU list中，被统计在Active(file)或Inactive(file)之中。
Cached	从磁盘读取文件的内存缓存(pagecache)。不包含SwapCached
SwapCached	曾经被换出的内存会被换回，但仍然在交换文件中(如果需要内存（应该是内存不足的情况），则不需要再次换出，因为它已经在交换文件中。这节省了I/O)
Active	最近使用的内存，除非绝对必要，否则通常不会回收。
Inactive	最近很少使用的内存。它更有资格被回收作其他用途
HighTotal:
HighFree	高端内存是指物理内存860MB以上的所有内存。高端内存区域是供用户空间程序使用的，或者用于pagecache。内核访问该内存时必须使用一些技巧，使其访问速度比lowmem慢。
LowTotal:
LowFree	lowmem可以用于任何highmem所用在的地方，内核也可以使用它来实现自身的数据结构。除其他事项外，它是Slab中分配所有内容的地方。当lowmem用完时，坏事就会发生。
SwapTotal	可用交换空间的总数
SwapFree	被从RAM中移除，暂时保存在磁盘上的内存
Dirty	等待被写回磁盘的内存
Writeback	正在被写回磁盘的内存
AnonPages	匿名页数量
AnonHugePages	匿名大页数量	总的来说，大页需要更多的手动配置和管理，但为需要它的应用程序提供稳定的性能改善。透明大页减少了管理负担，但其性能改进可能会因应用程序和工作负载的不同而变化，尤其是当系统频繁地合并和拆分大页时。选择使用哪一种技术取决于特定的应用需求和系统管理策略。
Mapped	已映射的文件，如库
Shmem	共享内存(shmem)和tmpfs使用的总内存
ShmemHugePages	Memory used by shared memory (shmem) and tmpfs allocated with huge pages
ShmemPmdMapped	Shared memory mapped into userspace with huge pages
Slab	in-kernel data structures cache
SReclaimable	Part of Slab, that might be reclaimed(回收), such as caches	缓存文件系统数据（如目录项缓存、inode缓存等）：这些是为了加快文件访问速度而缓存的文件系统的元数据。当内存需求增加时，这些数据可以被清除，因为它们可以从磁盘上重新加载。 Slab分配器缓存的对象：Slab分配器用于内核中频繁创建和销毁的小对象。其中一些Slab缓存是可回收的，特别是那些不经常访问的或可以重新生成的数据。
SUnreclaim	Part of Slab, that cannot be reclaimed on memory pressure	核心内核结构：如进程表、内核代码和静态分配的内核数据结构。这些是系统运行所必需的，不能被移除或压缩。 活跃的Slab分配器缓存的对象：一些Slab缓存对象是系统活动所必需的，例如用于网络协议栈的数据结构。这些不能被简单地回收，因为它们是当前系统操作的一部分。
PageTables	专用于最低级别页表的内存数量。
NFS_Unstable	发给NFS server但尚未写入硬盘的缓存页	NFS是网络文件共享系统 它主要功能是通过网络（一般是局域网）让不同的主机系统之间可以共享文件或目录 NFS客户端 (一般是应用 服务器 ，例如web)可以通过挂载（mount）的方式将NFS服务器端共享的数据目录挂载到NFS客户端本地系统中（就是某一个挂载点下）。
Bounce	Memory used for block device "bounce buffers"	设备驱动程序无法对高端内存执行直接内存访问I/O。相反，内核在低端内存中分配缓冲区，数据通过内核]缓冲区在高端内存和设备驱动程序之间传输。这个内核缓冲区通常称为回弹缓冲区(bounce buffer)，该过程被称为回弹或回弹缓冲。在早期的Linux 内核(早期的2.4及先前的内核版本)中，设备驱动程序无法直接访问高端内存中的虚址。换句话说，这些设备驱动程序无法对高端内存执行直接内存访问I/O。相反，内核在低端内存中分配缓冲区，数据通过内核缓冲区在高端内存和设备驱动程序之间传输。这个内核缓冲区通常称为回弹缓冲区(bounce buffer)，该过程被称为回弹或回弹缓冲。由于数据库服务器的I/O密集特征，回弹过程严重地降低了数据库服务器的性能。首先，回弹缓冲区会消耗低端内存，这可能导致内存短缺问题。其次，过量的回弹操作会引起系统占用时间较长，导致数据库系统完全变成CPU绑定的。数据库服务器性能领域的一个主要进展即是在最近的内核中消除了回弹缓冲机制。
WritebackTmp	FUSE用于临时回写缓冲区的内存	FUSE是一个允许非特权用户创建自己的文件系统而无需修改内核代码的框架。这种方式使得文件系统可以在用户空间中运行，而不是传统的在内核空间中运行。 通过FUSE，开发人员可以实现各种各样的文件系统，如云存储文件系统、加密文件系统等，而无需深入内核层面的开发。Writeback是操作系统中的一种内存管理机制，用于将更改后的数据（即“脏”数据）从内存写回到硬盘。这个过程可以是异步的，意味着数据可能会在内存中保留一段时间，直到系统决定将其写回磁盘。 在FUSE的上下文中，WritebackTmp指的是FUSE用于临时存储那些待回写到磁盘的数据的内存区域。这些临时回写缓冲区用于在数据被最终写入文件系统之前，暂时存储这些数据。 这种机制对于提高系统性能特别重要，因为它允许文件系统延迟磁盘写入操作，从而在一定程度上减少磁盘I/O操作的次数和等待时间，特别是在高负载情况下。 然而，这也意味着需要额外的内存来存储这些临时数据，这些内存的使用量可能会随着系统运行和FUSE文件系统活动的增加而增加。
CommitLimit	基于overcommit ratio ('vm.overcommit_ratio')，这是系统上当前可分配的内存总量。只有在启用了严格的超量分配机制(mode 2 in vm.overcommit_memory)时，才会遵守这个限制。CommitLimit的计算公式如下:CommitLimit = ([total RAM pages] - [total huge TLB pages]) * overcommit_ratio / 100 + [total swap pages]。例如，在一个具有1G物理RAM和7G swap的系统上，使用`vm.overcommit_ratio '为30时，则CommitLimit为7.3G。	vm.overcommit_memory。0 默认设置，不允许普通用户overcommit, 但是允许root用户轻微的overcommit.1 允许overcommit。2 不允许过度 overcommit。即允许分配超过所有物理内存和交换空间总和的内存。
Committed_AS	系统当前分配的内存量。是进程已分配的所有内存的总和，即使它们尚未“使用”这些内存。一个malloc()拥有1G内存的进程，但只接触了其中的300M，也将显示为使用了1G。这1G是由VM“提交”的内存，可以在分配应用程序的任何时候使用。如果在系统上启用了严格的超额分配(在vm.overcommit_memory中的模式2)，将不允许超出CommitLimit(上面详细说明)的分配。如果需要保证在内存成功分配之后，进程不会因为缺少内存而失败，那么这是很有用的。
VmallocTotal	total size of vmalloc memory area
VmallocUsed	amount of vmalloc area which is used
VmallocChunk	vmalloc区域中空闲的最大连续块

slab是什么

在Linux中，伙伴分配器（buddy allocator）是以页为单位管理和分配内存。但在内核中的需求却以字节为单位（在内核中面临频繁的结构体内存分配问题）。假如我们需要动态申请一个内核结构体（占 20 字节），若仍然分配一页内存，这将严重浪费内存。那么该如何分配呢？slab 分配器专为小内存分配而生。slab分配器分配内存以字节为单位，基于伙伴分配器的大内存进一步细分成小内存分配。换句话说，slab 分配器仍然从 Buddy 分配器中申请内存，之后自己对申请来的内存细分管理。

除了提供小内存外，slab 分配器的第二个任务是维护常用对象的缓存。对于内核中使用的许多结构，初始化对象所需的时间可等于或超过为其分配空间的成本。当创建一个新的slab 时，许多对象将被打包到其中并使用构造函数（如果有）进行初始化。释放对象后，它会保持其初始化状态，这样可以快速分配对象。

举例来说, 为管理与进程关联的文件系统数据, 内核必须经常生成struct fs_struct的新实例. 此类型实例占据的内存块同样需要经常回收(在进程结束时). 换句话说, 内核趋向于非常有规律地分配并释放大小为sizeof(fs_struct)的内存块. slab分配器将释放的内存块保存在一个内部列表中. 并不马上返回给伙伴系统. 在请求为该类对象分配一个新实例时, 会使用最近释放的内存块。S这有两个优点. 首先, 由于内核不必使用伙伴系统算法, 处理时间会变短. 其次, 由于该内存块仍然是”新”的，因此其仍然驻留在CPU硬件缓存的概率较高.

SLAB分配器的最后一项任务是提高CPU硬件缓存的利用率。 如果将对象包装到SLAB中后仍有剩余空间，则将剩余空间用于为SLAB着色。SLAB着色是一种尝试使不同SLAB中的对象使用CPU硬件缓存中不同行的方案。 通过将对象放置在SLAB中的不同起始偏移处，对象可能会在CPU缓存中使用不同的行，从而有助于确保来自同一SLAB缓存的对象不太可能相互刷新。 通过这种方案，原本被浪费掉的空间可以实现一项新功能。

通过命令sudo cat /proc/slabinfo可查看系统当前 slab 使用情况。以vm_area_struct结构体为例，当前系统已分配了 13014 个vm_area_struct缓存，每个大小为 216 字节，其中 active 的有 12392 个。

[root@VM-8-9-centos]# cat /proc/slabinfo
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
...
vm_area_struct     12392  13014    216   18    1 : tunables    0    0    0 : slabdata    723    723      0
mm_struct            184    200   1600   20    8 : tunables    0    0    0 : slabdata     10     10      0
shared_policy_node   5015   5015     48   85    1 : tunables    0    0    0 : slabdata     59     59      0
numa_policy           15     15    264   15    1 : tunables    0    0    0 : slabdata      1      1      0
radix_tree_node    15392  17234    584   14    2 : tunables    0    0    0 : slabdata   1231   1231      0
idr_layer_cache      240    240   2112   15    8 : tunables    0    0    0 : slabdata     16     16      0
kmalloc-8192          39     44   8192    4    8 : tunables    0    0    0 : slabdata     11     11      0
kmalloc-4096         117    144   4096    8    8 : tunables    0    0    0 : slabdata     18     18      0
kmalloc-2048         458    528   2048   16    8 : tunables    0    0    0 : slabdata     33     33      0
kmalloc-1024        1399   1424   1024   16    4 : tunables    0    0    0 : slabdata     89     89      0
kmalloc-512          763    800    512   16    2 : tunables    0    0    0 : slabdata     50     50      0
kmalloc-256         3132   3376    256   16    1 : tunables    0    0    0 : slabdata    211    211      0
kmalloc-192         2300   2352    192   21    1 : tunables    0    0    0 : slabdata    112    112      0
kmalloc-128         1376   1376    128   32    1 : tunables    0    0    0 : slabdata     43     43      0
kmalloc-96          1596   1596     96   42    1 : tunables    0    0    0 : slabdata     38     38      0
kmalloc-64         16632  20800     64   64    1 : tunables    0    0    0 : slabdata    325    325      0
kmalloc-32          1664   1664     32  128    1 : tunables    0    0    0 : slabdata     13     13      0
kmalloc-16          4608   4608     16  256    1 : tunables    0    0    0 : slabdata     18     18      0
kmalloc-8           4096   4096      8  512    1 : tunables    0    0    0 : slabdata      8      8      0
...

可以看到，系统中存在的 slab 有些形如 kmalloc-xxx 的 slab，我们称其为通用型 slab，用来满足分配通用内存。其他含有具体名字的 slab 我们称其为 专用 slab，用来为特定结构体分配内存，如 vm_area_struct、mm_struct 等。

为什么要分专用和通用 slab ？ 最直观的一个原因就是通用 slab 会造成内存浪费：出于 slab 管理的方便，每个 slab 管理的对象大小都是一致的，当我们需要分配一个处于 64-96字节中间大小的对象时，就必须从保存 96 字节的 slab 中分配。而对于专用的 slab，其管理的都是同一个结构体实例，申请一个就给一个恰好内存大小的对象，这就可以充分利用空间。

SLAB分配器为什么会有剩余空间？

1. 对象大小与分配粒度不匹配：操作系统通常以固定的"页"大小（例如4KB）来分配内存。如果一个SLAB的大小不是分配粒度（页大小）的整数倍，那么在分配这个SLAB时就会产生未完全使用的空间。

   1. 为什么不能在同一个页上，存储另一个slab呢

      1. 缓存利用率下降：将同类型的对象集中存储可以提高CPU缓存的局部性（Locality），因为相似的数据被访问的可能性更高，这有助于提高缓存命中率。如果在一个页中混合存储不同SLAB的对象，可能会降低缓存的局部性。

      2. 管理复杂度增加：SLAB分配器通过预分配整个SLAB来简化内存分配和释放的过程，从而减少了管理开销。如果一个页中可以包含来自不同SLAB的对象，那么需要更复杂的管理逻辑来跟踪哪些部分属于哪个SLAB，这增加了开销。

      3. 内存碎片问题：虽然看似在同一个页上存储多个SLAB的部分可以更充分地利用内存，但实际上这样做可能会导致更细粒度的碎片问题。当其中一部分SLAB被完全释放时，可能无法回收整个页，因为页中还存有来自其他SLAB的对象。

   2. 如果一个对象只有200byte的长度，那slab也会为这个对象分配一页的大小吗，导致有了很多的剩余空间

      当对象的大小远小于一页的大小时（通常一页是4KB），SLAB分配器不会为每个对象单独分配一页内存。相反，SLAB分配器的工作方式是将多个这样的小对象集中存储在一个SLAB中，这个SLAB是从Buddy系统分配的一页或多页内存。

      具体到您提到的200字节的对象，SLAB分配器的处理方式大致如下：

      1. SLAB创建：分配器从Buddy系统请求一页（或根据配置可能是多页）内存。这页内存成为一个新的SLAB。

      2. 对象存储：在这个SLAB内，分配器会按照对象的大小（在这个例子中是200字节）来划分内存，以便存放多个这样大小的对象。由于每个对象都是200字节，一个4KB的页可以容纳大约20个这样的对象（实际上可能少于这个数，因为还需要考虑到对象对齐和管理结构占用的空间）。

      3. 空间利用：通过这种方式，SLAB分配器能够有效地利用页内存，将多个小对象集中存储在同一个SLAB中，显著减少了因小对象频繁分配和释放而可能产生的内存碎片。

      4. 剩余空间管理：即便如此，由于对象大小不可能完美地匹配页大小，可能会有一些未使用的空间。SLAB分配器通过管理手段（如前面提到的着色技术）尽量减少这种未使用空间的影响，提高内存利用率。

      因此，SLAB分配器是专门设计来处理这种小对象频繁创建和销毁的场景，通过将多个小对象集中在单个或几个连续的内存页中，以减少内存碎片和提高内存利用率。

2. 内存对齐要求：为了提高访问速度，CPU通常要求数据按一定的边界对齐，比如4字节或8字节边界。这种对齐要求可能会导致在对象之间或在SLAB的末尾留下小块未使用的空间。

   1. 边界对齐为什么可以提高访问速度

      1. 减少内存访问次数：当数据按照硬件要求的边界对齐时，CPU可以在较少的内存访问中读取或写入所需的数据。例如，假设一个32位的整数（4字节）位于一个4字节对齐的地址上，CPU可以一次性读取这个整数。如果这个整数跨越了两个对齐的边界（例如，开始于一个3字节对齐的地址），CPU可能需要进行两次内存访问来读取完整的整数，从而降低了效率。

         1. 如果这个整数跨越了两个对齐的边界，cpu不能直接读取8个字节吗

            当CPU遇到一个跨越两个对齐边界的整数时，理论上它确实可以通过一次更宽的读取操作（如读取8个字节）来获取这个整数，前提是CPU的架构支持这种宽度的读取，并且这个更宽的读取操作是对齐的。然而，这种方法并不总是理想的，原因如下：

            1. 效率问题：虽然通过一次读取更多的数据可以获得所需的非对齐整数，但这种方法可能不是最高效的。更宽的读取意味着CPU可能会读取一些不需要的数据，这会浪费带宽并可能增加缓存行的替换，特别是如果额外读取的数据不会被立即使用的话。

            2. 处理器支持：并非所有处理器都能高效地处理宽度更大的非对齐数据访问。某些处理器在执行非对齐访问时可能会遇到性能损失，或者需要额外的指令和周期来处理这些访问。这会降低程序的整体性能。

            3. 逻辑复杂度：即使处理器可以一次读取8个字节来获取一个非对齐的整数，但这之后还需要进行额外的逻辑操作来提取所需的数据。这些操作可能包括位移（shift）和掩码（mask）操作，这些操作本身就需要额外的处理器周期和指令。

            4. 兼容性和可移植性：依赖于特定处理器能力进行宽度更大的读取可能会影响代码的兼容性和可移植性。如果代码被移植到只支持或更优化了对齐访问的处理器上，性能可能会受到影响。

            总的来说，尽管直接读取更宽的数据范围是一种可能的技术手段，但从性能优化和代码的可移植性角度考虑，保持数据对齐是更推荐的做法。对齐的数据访问可以确保在不同的处理器和系统架构上获得一致且优化的性能表现。

         2. 利用缓存行效率：现代CPU使用缓存来减少访问主内存的延迟。缓存以缓存行为单位工作，常见的缓存行大小是64字节。如果数据对齐于缓存行的边界，可以更有效地利用缓存行的容量，减少缓存失效的情况。不对齐的数据可能会跨越两个缓存行，增加了缓存行加载的次数，从而降低了访问速度。

            1. cpu怎么知道要缓存什么内存数据

               CPU决定缓存什么内存数据主要是基于硬件层面的自动机制，这些机制设计来预测和优化内存访问模式，提高数据访问效率。主要方法包括：

               1. 空间局部性（Spatial Locality）：这是基于一个观察：如果一个数据被访问，那么其附近的数据很可能不久后也会被访问。因此，当CPU访问内存中的一个数据时，它不仅会加载这个特定的数据到缓存中，还会加载邻近的数据。这是因为内存是以缓存行为单位加载的（典型的缓存行大小是64字节），而不是单独加载每个字节或字。

               2. 时间局部性（Temporal Locality）：基于另一个观察：如果一个数据被访问，那么它很可能在不久的将来再次被访问。CPU的缓存机制利用这一点，通过保留最近访问的数据在缓存中，以便快速再次访问。

               3. 预取策略（Prefetching）：许多现代CPU包含预取逻辑，可以预测哪些数据将被需要，并在这些数据被请求之前就加载它们到缓存中。预取是根据程序的访问模式自动进行的，例如，如果检测到内存访问的线性模式，预取器可以提前加载后续的内存块。

               4. 替换策略（Replacement Policies）：当缓存满了并且需要加载新的数据时，CPU必须决定哪些旧的数据被替换。常见的替换策略包括最不经常使用（LFU）、最近最少使用（LRU）等，它们试图保留最可能被再次访问的数据在缓存中。

               5. 写策略（Write Policies）：当数据需要写回到内存时，CPU的缓存也有策略来决定何时和如何更新内存。这些策略包括立即写回（Write-Through）和写回（Write-Back），前者每次数据改变时立即更新主内存，而后者则是在缓存行被替换时才写回改变。

               这些机制和策略共同工作，使CPU能够高效地管理缓存，以减少对慢速主内存的访问，从而提高整体的系统性能。

         3. 减少处理器内部的调整开销：对齐的数据允许处理器直接在其自然边界上操作数据，无需执行额外的操作来处理边界不对齐的数据。这样可以减少CPU内部的调整开销，提高数据处理速度。

         4. 硬件支持：许多处理器架构对于非对齐的内存访问有额外的约束或不支持。例如，某些架构可能在访问非对齐内存时产生异常，需要操作系统通过更多的处理步骤来纠正，这显著增加了访问延迟。因此，保持数据对齐是遵守硬件约束和优化性能的一种方式。

         总结来说，边界对齐通过减少内存访问次数、优化缓存利用、减少处理器内部调整开销以及符合硬件设计的要求，来提高数据访问速度和整体系统性能。

3. 减少碎片：即使可以完美地填满一个SLAB，系统为了减少碎片和优化后续分配，可能故意留出一些空间。

   留出来的这些空间确实是在一个SLAB内部，也就是说，在一个SLAB（例如4KB大小）中，即便有能力完全填满它（分配尽可能多的对象），系统可能会选择不这么做。这里的空间留出有几个具体目的：

   1. 避免完全填满导致的碎片：如果一个SLAB被完全填满，那么下一次相同大小的内存请求就需要分配一个新的SLAB。这可能导致如果有小量的内存被释放，就会留下很小的未使用空间，这种小块的碎片难以被再次利用，因为它们可能不适合新的内存请求的大小。通过不完全填满一个SLAB，留出一定的空间，这可以让后续的相同类型的内存请求直接使用这些预留空间，减少碎片的产生。

   2. 提高内存分配效率：当有新的内存请求时，如果一个SLAB中已经预留有足够的空间，这个请求就可以立即得到满足，而不需要系统去进行新的SLAB分配或是在多个SLAB之间寻找可用空间。这样可以减少内存分配的时间，提高系统效率。

   3. 优化内存利用：通过控制SLAB中空间的使用，系统可以更灵活地应对不同大小的内存请求，优化整体的内存利用率。例如，如果一个SLAB完全填满了，但后续大部分内存释放了，这就导致了一个几乎空的SLAB占用宝贵的内存资源。而如果有预留空间，就可以更灵活地调整和重新分配这些空间，避免大量空闲SLAB的产生。

   总之，这种策略是一种预防措施，通过留出一些空间来减少未来可能出现的问题，如内存碎片和分配效率降低。这样做虽然可能会牺牲一点当前的内存使用率，但从长远来看，可以提高系统的稳定性和性能。

缓存冲突是什么

当多个数据项映射到同一缓存行时，就会发生缓存冲突。这会导致已缓存的数据被新数据替换，从而降低缓存效率。

SLAB着色的目的是减少这种缓存冲突，方法是调整存储在SLAB中对象的起始位置。具体来说：

• 在没有着色的情况下，每个SLAB中的对象都是从固定的起始位置分配的，这可能导致来自不同SLAB的对象落在CPU缓存的同一行上，增加缓存冲突的风险。

• 通过SLAB着色，系统会为每个SLAB分配一个小的起始偏移（“着色”），使得每个SLAB中的对象在物理内存中的位置略有不同。这种偏移使得同一SLAB缓存的对象更有可能使用CPU缓存中的不同行，减少了缓存冲突。

多个数据项映射到同一缓存行的情况通常发生在以下两种情况之一：

• 空间局部性：如果两个频繁访问的数据项存储得很近（例如，在数组中相邻），它们可能会被加载到同一个缓存行中。这是理想的情况，可以提高缓存利用率。

• 缓存冲突：当两个数据项的地址导致它们根据缓存的映射策略被分配到同一缓存行时，即使它们在内存中的位置相距甚远。这种情况下，一个数据项的更新可能会导致另一个数据项被从缓存中逐出，这是不理想的。

例如，假设CPU缓存行能够存储32字节的数据，而一个对象大小为32字节。如果每个对象都从32字节的边界开始分配，那么来自不同SLAB的对象很可能会映射到相同的缓存行。通过SLAB着色，第一个SLAB中的对象可以从0字节偏移开始分配，而第二个SLAB中的对象从8字节偏移开始分配，第三个从16字节偏移开始，依此类推。这样，即使对象大小与缓存行大小相匹配，对象也更有可能落在不同的缓存行中，从而减少缓存冲突。

Linux内核使用一套机制来标记slab是属于可回收还是不可回收的。这个机制是什么

Linux内核使用多个机制和策略来管理和标记内存页，判断它们是属于可回收（SReclaimable）还是不可回收（SUnreclaim）。这些机制涉及内存页的使用方式、内存分配器的行为、以及特定的内核数据结构。下面是一些核心机制和概念：

1. 页面类型（Page Types）

Linux内核为内存页维护了一个类型系统，这个系统通过跟踪页的状态和用途来确定它们是否可以被回收。例如，内核可以标记某些页为缓存页（用于文件缓存）或者Slab页（用于Slab分配器）。通过这些类型信息，内核可以识别出哪些页是可回收的（如某些类型的缓存页）。

1. 内存分区（Memory Zones）

Linux将物理内存分为多个区域或“区”（zones），例如DMA区、正常区和高端区。这些区代表了不同的物理内存特性和用途。内核根据内存页所属的区以及当前的内存压力情况来决定回收策略。某些区中的页可能更容易被标记为可回收，特别是在内存紧张时。

1. 活动/非活动列表（Active/Inactive Lists）

Linux内核使用活动和非活动列表来管理缓存页。这些列表帮助内核跟踪哪些页是经常访问的（活动的），哪些是较少访问的（非活动的）。非活动列表中的页更有可能被标记为可回收，因为它们被认为是较少使用的。

1. cgroups 和内存控制器

控制组（cgroups）提供了资源管理的能力，允许内核限制、记录和隔离进程组使用的资源量，包括内存。通过使用内存控制器（memory controller），系统管理员可以细粒度地控制不同控制组中的内存使用情况，包括哪些内存可以被回收。

1. 回收策略和算法

内核使用一系列回收策略和算法（如页面替换算法）来决定哪些页应该被回收。这些策略考虑了页的访问频率、修改状态（脏页或干净页）、以及它们是否属于可回收内存的一部分。

结论

Linux内核通过这些机制和其他策略来动态管理内存，确保系统的运行效率和稳定性。通过标记内存页为可回收或不可回收，内核能够在内存需求增加时优先回收那些不太可能影响系统性能的页，同时保留那些对系统运行至关重要的页。这是一个复杂的过程，涉及到内核的多个子系统和组件，旨在最大化内存的有效使用，同时减少对系统性能的影响。

file LRU lists是什么

Lru（Least Recently Used）即最近最少使用算法。内核在管理用户内存页（user page）时便是应用了Lru算法。User page 包含匿名页（anonymous page）和文件页（file page）。进程私有页为匿名页，例如，Malloc函数申请的内存都为匿名页；进程间共享页为文件页，例如，read/write/mmap file时产生的内存消耗为文件页（又称page cache）。今天我们以管理文件页的lru链表为例子讲解lru在kernel内存管理方面的应用

1.1 Read系统调用

当用户调用read系统调用访问一个16K的文件，文件系统会先在内存中寻找是否有对应的page cache（即文件页）已经被加载，如果没有则新申请一个page，从磁盘读取对应偏移的内容到新申请的page中，然后再将page cache中的内容copy到用户事先准备好的内存buffer中，返回给用户。read系统调用结束。这个流程里面涉及到两段内存的使用，第一是磁盘的缓存page cache，第二个是用户事先备好的buffer（即read函数的实参），这两者是简单的copy的关系。

1.2 Mmap系统调用

当用户调用mmap系统调用映射一个16k的文件时，会先建立vma，直接返回用户虚拟地址，当用户访问此虚拟地址时，会产生缺页异常，分配页表和一个新page，将page map到页表与vma上。用户操作虚拟地址时，直接操作的page cache，这里是和read系统调用最主要的区别。

2. File lru list原理

Page杂乱的分布在内存中，其中包括使用的/未使用的，内核用的/用户用的，文件页/匿名页，我们按属性将用户地址空间的页串成多个链表，图3中仅列举了匿名活跃lru，匿名不活跃lru，文件活跃lru，文件不活跃lru，除此之外还有unevictable lru(即不可回收的，本文不讨论)。 lru本质上就是实现了FIFO功能的链表, add/delete分别发生在链表两头。

具体算法，后面再看

。。。

low watermarks in each zone是什么

在Linux内存管理中，"low watermarks" 是指在每个内存区域（zone）中的一个阈值，用来保证系统操作的最低内存需求。Linux将物理内存划分为多个区域（例如，DMA, DMA32, Normal, HighMem等），以适应不同类型的内存分配需求。每个区域都有自己的一系列"watermarks"（水位标记），包括"low", "min", 和"high"这三个水平。这些水位标记用于内存的水平平衡和回收策略，帮助操作系统决定何时启动内存回收过程以回收空间，或者何时停止某些内存分配以避免资源耗尽。

• Low Watermark (低水位): 当某个区域的可用内存降至低水位标记以下时，系统会触发内存回收机制，开始回收内存页。这个阈值旨在确保还有足够的内存页可用于满足紧急分配请求，避免内存耗尽导致的系统不稳定。

• Min Watermark (最小水位): 是另一个检查点，用于确保即使在执行内存回收操作时，也有足够的内存页可供关键系统操作使用。

• High Watermark (高水位): 表示当区域中的可用内存超过这个阈值时，内存回收过程可以放慢甚至停止，因为系统认为有足够的内存可用于分配。

这些水位标记是动态管理的，并且可以根据系统的总体内存使用情况和负载进行调整，以优化性能和资源利用率。通过这种方式，Linux内存管理旨在在系统的运行效率和稳定性之间取得平衡。

怎么回收

当Linux内存中某个区域的可用内存降低到低水位标记（low watermark）以下时，系统将触发内存回收机制来回收内存。这个过程涉及几个关键步骤和策略：

1. 页面回收 (Page Reclaim)

内存回收的首要目标是回收页面（pages），尤其是那些可以被安全释放的页面。这主要包括：

• 回收不活跃或者最少使用的页面：内核会检查内存中的页面，首先回收那些不常访问的页面。这是通过检查页面的访问位（access bit）来完成的，如果页面在一段时间内没有被访问，它将被标记为可回收。

• 交换出（Swapping Out）：对于那些已经被分配但是不常用的页面，内核可能会将它们写入到交换空间（swap space），从而释放物理内存。

2. 清理缓存

Linux使用部分内存作为缓存（例如文件系统缓存），以加快文件访问速度。当内存紧张时，这些缓存中的数据可以被清理以回收内存，尤其是那些容易再次获取或计算的数据。

3. 回收内核对象

内核也可能分配特定的对象用于自己的数据结构。在内存紧张时，内核会尝试回收那些不再需要或者可以延迟使用的内核对象。

4. 内存压缩

在支持内存压缩的系统上，内核可以通过压缩内存中的数据来释放空间。这个过程会减少物理内存的使用，但会增加CPU的负担。

触发机制

• 直接回收（Direct Reclaim）：当进程尝试分配内存而可用内存不足时，该进程会直接参与到内存回收过程中，直到有足够的内存可以用于分配。

• kswapd守护进程：Linux有一个名为kswapd的守护进程，负责监视内存使用情况。当内存使用接近low watermark时，kswapd会开始在后台运行，尝试回收内存到一个健康的水平（通常是高水位标记以上）。

这些回收策略和机制共同作用，以确保系统即使在内存紧张的情况下也能保持运行，尽量避免因为内存耗尽导致的性能下降或系统崩溃。