网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
cat /proc/sys/vm/lowmem\_reserve\_ratio
256 256 32
内核利用上述的protection数组计算每个zone的预留page量，计算出来也是数组形式，从/proc/zoneinfo里可以查看：
Node 0, zone DMA
pages free 1355
min 3
low 3
high 4
:
:
numa\_other 0
protection: (0, 2004, 2004, 2004)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pagesets
cpu: 0 pcp: 0
:
在进行内存分配时，这些预留页数值和watermark相加来一起决定现在是满足分配请求，还是认为空闲内存量过低需要启动回收。
例如，如果一个normal区(index = 2)的页申请来试图分配DMA区的内存，且现在使用的判断标准是watermark[low]时，内核计算出 page_free = 1355，而watermark + protection[2] = 3 + 2004 = 2007 > page_free，则认为空闲内存太少而不予以分配。如果分配请求本就来自DMA zone，则 protection[0] = 0会被使用，而满足分配申请。
zone[i] 的 protection[j] 计算规则如下：
(i < j):
zone[i]->protection[j]
= (total sums of present\_pages from zone[i+1] to zone[j] on the node)
/ lowmem\_reserve\_ratio[i];
(i = j):
(should not be protected. = 0;
(i > j):
(not necessary, but looks 0)
默认的 lowmem_reserve_ratio[i] 值是：
256 (if zone[i] means DMA or DMA32 zone)
32 (others).
从上面的计算规则可以看出，预留内存值是ratio的倒数关系，如果是256则代表 1/256，即为 0.39% 的高端zone内存大小。
如果想要预留更多页，应该设更小一点的值，最小值是1（1/1 -> 100%）。
- 和min_free_kbytes（watermark）的配合示例
下面是一段某线上服务器（96G）内存申请失败时打印出的log：
[38905.295014] java: page allocation failure. order:1, mode:0x20, zone 2
[38905.295020] Pid: 25174, comm: java Not tainted 2.6.32-220.23.1.tb750.el5.x86\_64 #1
...
[38905.295348] active\_anon:5730961 inactive\_anon:216708 isolated\_anon:0
[38905.295349] active\_file:2251981 inactive\_file:15562505 isolated\_file:0
[38905.295350] unevictable:1256 dirty:790255 writeback:0 unstable:0
[38905.295351] free:113095 slab\_reclaimable:577285 slab\_unreclaimable:31941
[38905.295352] mapped:7816 shmem:4 pagetables:13911 bounce:0
[38905.295355] Node 0 DMA free:15796kB min:4kB low:4kB high:4kB active\_anon:0kB inactive\_anon:0kB active\_file:0kB inactive\_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15332kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab\_reclaimable:0kB slab\_unreclaimable:0kB kernel\_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback\_tmp:0kB pages\_scanned:0 all\_unreclaimable? yes
[38905.295365] lowmem\_reserve[]: 0 1951 96891 96891
[38905.295369] Node 0 DMA32 free:380032kB min:800kB low:1000kB high:1200kB active\_anon:46056kB inactive\_anon:10876kB active\_file:15968kB inactive\_file:129772kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1998016kB mlocked:0kB dirty:20416kB writeback:0kB mapped:0kB shmem:0kB slab\_reclaimable:11716kB slab\_unreclaimable:160kB kernel\_stack:176kB pagetables:112kB unstable:0kB bounce:0kB writeback\_tmp:0kB pages\_scanned:576 all\_unreclaimable? no
[38905.295379] lowmem\_reserve[]: 0 0 94940 94940
[38905.295383] Node 0 Normal free:56552kB min:39032kB low:48788kB high:58548kB active\_anon:22877788kB inactive\_anon:855956kB active\_file:8991956kB inactive\_file:62120248kB unevictable:5024kB isolated(anon):0kB isolated(file):0kB present:97218560kB mlocked:5024kB dirty:3140604kB writeback:0kB mapped:31264kB shmem:16kB slab\_reclaimable:2297424kB slab\_unreclaimable:127604kB kernel\_stack:12528kB pagetables:55532kB unstable:0kB bounce:0kB writeback\_tmp:0kB pages\_scanned:0 all\_unreclaimable? no
[38905.295393] lowmem\_reserve[]: 0 0 0 0
[38905.295396] Node 0 DMA: 1\*4kB 2\*8kB 0\*16kB 1\*32kB 2\*64kB 0\*128kB 1\*256kB 0\*512kB 1\*1024kB 1\*2048kB 3\*4096kB = 15796kB
[38905.295405] Node 0 DMA32: 130\*4kB 65\*8kB 75\*16kB 72\*32kB 95\*64kB 22\*128kB 10\*256kB 7\*512kB 4\*1024kB 2\*2048kB 86\*4096kB = 380032kB
[38905.295414] Node 0 Normal: 12544\*4kB 68\*8kB 0\*16kB 0\*32kB 0\*64kB 0\*128kB 0\*256kB 0\*512kB 0\*1024kB 0\*2048kB 1\*4096kB = 54816kB
[38905.295423] 17816926 total pagecache pages
1）从第一行log“order:1, mode:0x20”可以看出来是GFP_ATOMIC类型的申请，且order = 1(page = 2 )
2）第一次内存申请尝试
在__alloc_pages_nodemask()里，首先调用 get_page_from_freelist() 尝试第一次申请，使用的标志位是 ALLOC_WMARK_LOW|ALLOC_CPUSET，它会对每个zone都做 zone_watermark_ok()的检查，使用的就是传进的watermark[low]阈值。
在zone_watermark_ok()里会考虑z->lowmem_reserve[]，导致在normal上的申请不会落到低端zone。比如对于DMA32：
free pages = 380032KB = 95008 pages < low(1000KB = 250 pages) + lowmem\_reserve[normal](94940) = 95190
所以就认为DMA32也不平不ok，同理更用不了DMA的内存。
而对于normal自己内存来说，free pages = 56552 KB = 14138 pages，也不用考虑lowmem_reserve(0)，但这时还会考虑申请order(1)，减去order 0的12544个page后只剩 14138 - 12544 = 1594，也小于 low / 2 = (48788KB=12197pages) / 2 = 6098 pages。
所以初次申请尝试失败，进入__alloc_pages_slowpath() 尝试进行更为积极一些的申请。
3)第二次内存申请尝试
__alloc_pages_slowpath()首先是通过 gfp_to_alloc_flags() 修改alloc_pages，设上更为强硬的标志位。这块根据原来的GFP_ATOMIC会设上 ALLOC_WMARK_MIN | ALLOC_HARDER | ALLOC_HIGH。但注意的是不会设上 ALLOC_NO_WATERMARKS 标志位。这个标志位不再判断zone的水位限制，属于优先级最高的申请，可以动用所有的reserve内存，但条件是（!in_interrupt() && ((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))))，即要求不能在中断上下文，且是正在进行回收（例如kswapd）或者正在退出的进程。
之后进入拿着新的alloc_pages重新进入get_page_from_pagelist() 尝试第二次申请，虽然有了 ALLOC_HARDER和ALLOC_HIGH，但是不幸的是在3个zone的zone_watermark_ok检查中还是都无法通过，例如对于DMA32：
free pages = 380032KB = 95008 pages
因为设上了ALLOC\_HIGH 所以会将得到的watermark[min]减半，即min = min/2 = 800K / 2 = 400K = 100pages
而又因为设上了ALLOC\_HARDER，会再将min砍去1/4，即min = 3 \* min / 4 = 100 pages \* 3 / 4 = 75 pages
即便如此，min(75 pages) + lowmem\_reserve[normal](94940) = 95015，仍大于free pages，仍认为无法分配内存，同理DMA也不不成功，而normal中 free pages里连续8K的页太少也无法满足分配
第二次失败后，由于没有ALLOC_NO_WATERMARK也不会进入__alloc_pages_high_priority 进行最高优先级的申请，同时由于是GFP_ATOMIC类型的分配不能阻塞回收或者进入OOM，因此就以申请失败告终。
遇到此种情况可以适当调高 min_free_kbytes 使kswapd较早启动回收，使系统一直留有较多的空闲内存，同时可以适度降低 lowmem_reserve_ratio（可选），使得内存不足的情况下（主要是normal zone）可以借用DMA32/DMA的内存救急（注意不能也不能过低）。
最后的话
最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！
资料预览
给大家整理的视频资料：
给大家整理的电子书资料：
如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
里获取！](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
965
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
