你知道Linux里D进程会搞事吗?

前言

这篇文章是一位大神在实际项目中遇到问题并分析总结出来的,作为新手,能接触到这类文章应该是受益匪浅,这位同学现在在魅族工作,以后也会一直在魅族工作,是Linux 方面linux重启命令的专家,「魅族还有另一个Linux 大神,知道的自然知道了」,不知道大家发现没有,最近文章底部的小guanggao被我撤掉了,我就linux系统是想让大家看文章的时候,能有一种家的感觉,系统运维工资一般多少如果觉得这位linux操作系统基础知识同学文章不错的,支持一下,支持方式不做限制,好了,不吹牛了,看下面的正文。

Description

一个项目中偶现几十上百个 D 进程卡住在 shrink_inactive_list,导致卡顿/卡死/android SWT 等问题,前前后后数据漫游,提交了 3 次系统/运维修复,还没有彻底解决。

山重水复疑无路

LOG:

[149459.897408] [3:2065:watchdog] Binder:1042_16 D 0 9917 635 0x00000008  
[149459.897427] [3:2065:watchdog] Call trace:
[149459.897435] [3:2065:watchdog] [<ffffff8bf28852d4>] _switch_to+0xb4/0xc0
[149459.897452] [3:2065:watchdog] [<ffffff8bf3a1f6a0>] _schedule+0x7f0/0xad0
[149459.897468] [3:2065:watchdog] [<ffffff8bf3a1f9f0>] schedule+0x70/0x90
[149459.897485] [3:2065:watchdog] [<ffffff8bf3a23b00>] schedule_timeout+0x548/0x668
[149459.897502] [3:2065:watchdog] [<ffffff8bf2959028>] msleep+0x28/0x38
[149459.897517] [3:2065:watchdog] [<ffffff8bf2a1ff38>] shrink_inactive_list+0x118/0x998
[149459.897534] [3:2065:watchdog] [<ffffff8bf2a1cb10>] shrink_node_memcg+0xa18/0x1100
[149459.897552] [3:2065:watchdog] [<ffffff8bf2a1f0b0>] shrink_node+0x108/0x2f8
[149459.897568] [3:2065:watchdog] [<ffffff8bf2a1bcb0>] do_try_to_free_pages+0x178/0x380
[149459.897586] [3:2065:watchdog] [<ffffff8bf2a1b9d0>] try_to_free_pages+0x370/0x4d8
[149459.897605] [3:2065:watchdog] [<ffffff8bf2a071b8>] _alloc_pages_nodemask+0x868/0x1380
[149459.897623] [3:2065:watchdog] [<ffffff8bf2a13784>] __do_pagecache_readahead+0xbc/0x358
[149459.897640] [3:2065:watchdog] [<ffffff8bf29fde4c>] filemapfault+0x11c/0x600
[149459.897647] [3:2065:watchdog] [<ffffff8bf2b479f8>] ext4_filemap_fault+0x30/0x50
[149459.897664] [3:2065:watchdog] [<ffffff8bf2a47f38>] handle_pte_fault+0xb38/0xfa8
[149459.897681] [3:2065:watchdog] [<ffffff8bf2a485c8>] handle_mm_fault+0x1d0/0x328
[149459.897699] [3:2065:watchdog] [<ffffff8bf28a3668>] do_page_fault+0x2a0/0x3e0
[149459.897716] [3:2065:watchdog] [<ffffff8bf28a3364>] do_translation_fault+0x44/0xa8
[149459.897732] [3:2065:watchdog] [<ffffff8bf2880b74>] do_mem_abort+0x4c/0xd0
[149459.897750] [3:2065:watchdog] [<ffffff8bf2882c78>] el0_da+0x20/0x24
[149459.897767] [3:2065:watchdog] Binder:1042_19 D 0 11188 635 0x00000008
[149459.897786] [3:2065:watchdog] Call trace:
[149459.897797] [3:2065:watchdog] [<ffffff8bf28852d4>] _switch_to+0xb4/0xc0
[149459.897804] [3:2065:watchdog] [<ffffff8bf3a1f6a0>] _schedule+0x7f0/0xad0
[149459.897820] [3:2065:watchdog] [<ffffff8bf3a1f9f0>] schedule+0x70/0x90
[149459.897835] [3:2065:watchdog] [<ffffff8bf3a23b00>] schedule_timeout+0x548/0x668
[149459.897853] [3:2065:watchdog] [<ffffff8bf2959028>] msleep+0x28/0x38
[149459.897868] [3:2065:watchdog] [<ffffff8bf2a1ff38>] shrink_inactive_list+0x118/0x998
[149459.897887] [3:2065:watchdog] [<ffffff8bf2a1cb10>] shrink_node_memcg+0xa18/0x1100
[149459.897904] [3:2065:watchdog] [<ffffff8bf2a1f0b0>] shrink_node+0x108/0x2f8
[149459.897922] [3:2065:watchdog] [<ffffff8bf2a1bcb0>] do_try_to_free_pages+0x178/0x380
[149459.897940] [3:2065:watchdog] [<ffffff8bf2a1b9d0>] try_to_free_pages+0x370/0x4d8
[149459.897957] [3:2065:watchdog] [<ffffff8bf2a071b8>] __alloc_pages_nodemask+0x868/0x1380
[149459.897977] [3:2065:watchdog] [<ffffff8bf2a13784>] _do_page_cache_readahead+0xbc/0x358
[149459.897996] [3:2065:watchdog] [<ffffff8bf29fde4c>] filemap_fault+0x11c/0x600
[149459.898013] [3:2065:watchdog] [<ffffff8bf2b479f8>] ext4_filemap_fault+0x30/0x50
[149459.898031] [3:2065:watchdog] [<ffffff8bf2a47f38>] handle_pte_fault+0xb38/0xfa8
[149459.898048] [3:2065:watchdog] [<ffffff8bf2a485c8>] handle_mm_fault+0x1d0/0x328
[149459.898065] [3:2065:watchdog] [<ffffff8bf28a3668>] do_page_fault+0x2a0/0x3e0
[149459.898083] [3:2065:watchdog] [<ffffff8bf28a3364>] do_translation_fault+0x44/0xa8
[149459.898100] [3:2065:watchdog] [<ffffff8bf2880d18>] do_el0_ia_bp_hardening+0xc0/0x158
[149459.898118] [3:2065:watchdog] [<ffffff8bf2882c98>] el0_ia+0x1c/0x20

现象:
大量进程从缺页异常入口,调用内存回收接口:
shrink_inactive_list -> msleelinux删除文件命令p ,使得该进程状态变为 D.

void msleep(unsigned int msecs) 
{
unsigned long timeout = msecs_to_jiffies(msecs) + 1;


while (timeout)
timeout = schedule_timeout_uninterruptible(timeout);
}
signed long __sched schedule_timeout_uninterruptible(signed long timeout)   
{
__set_current_state(TASK_UNINTERRUPTIBLE);
return schedule_timeout(timeout);
}

D 进程就是被设置了 TASK_UNINTERRUlinuxPTIBLE 进程状态,不可中断的睡眠状态数据漫游是什么意思
不可中断,指的并不是 CPU 不响应外部硬件数据透视表的中断,而是指进程不响应异步信号,信号只会挂到信号队列,而没有机linux必学的60个命令会去立即执行。
它不占用 CPU ,也不能被杀掉,很直观的现象就是,kill -9 一个 D 进程,是没有效果的,只有等进程获得资源被唤醒才处理信号,才处理 SIGKILL。
「进程是很有脾气的,不知道你们有没有遇到那种钻牛角尖的人,拿系统/运维我儿子来举例一下,有时候他想找到他的玩具火箭,就一直在那里闹,一定要我们帮他找到他的玩具火箭位置,其他事情就是不干,你用坦克哄他也不行,哄他看小猪佩奇也不行数据透视表
D进程也是一样,必须要等有他等到的那个事件为数据分析师止」

static noinline_for_stack unsigned long 
shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
struct scan_control *sc, enum lru_list lru)
{
......


while (unlikely(too_many_isolated(pgdat, file, sc, stalled))) {


if (stalled)
return 0;


/* wait a bit for the reclaimer. */
msleep(100); // 卡在这里
stalled = true;




/* We are about to die and free our memory. Return now. */
if (fatal_signal_pending(current))
return SWAP_CLUSTER_MAX;
}
......

初步定位:
该函数已经有跳出功能,不会一直卡住,最多 2 次就会退出去。说明是大量的进程疯狂地调用 shrink_inactive_list 又被阻塞了一数据恢复软件免费版下子,linux命令又退出去,又掉进来。
所以,不是一直卡死,而是性能瓶颈拥堵在这个地方,congestion数据分析师 「拥挤堵车的意思」。
从上层 systrace 也能看到,很有规数据恢复律的大概 110ms 一段的 D 状态,一个进程甚至可以持续几十秒。

说明隔离页数据库面过多,sleep 100ms,猜测linux常用命令目的是

  1. 给时间处理隔离页面,回写文件页到磁盘
  2. 是控制并发,也许另一个 cpu 也在同样的回收流程导致隔离页在时刻变大。

所以初步定了两个方向和疑点:
一是内存回收瓶颈,内存回收不及时,内存需求量巨大,而 LMK 没触发,内存有很多匿名页,都在回收和回写文件页等。
二是 io 读写瓶颈,io 速率慢,某个时间段速率变慢,ufs 频率低,上层读写大量数据,io 占用率过高等。
需要澄清这些疑点。
插播一些背景知识

page cachlinux重启命令e

导致这个情况数据的原因是:
进程在申请内存的时候,发现该 zone 的 freelist 上已经没有足够的内存可用,所以不得不去从该 zone 的 LRU 链表里回收 inactive 的page,这种linux删除文件命令情况就是linux重启命令 direct reclaim(直接回收)。direct reclaim 会比较消耗时间的原因是,如果回收的是 dirty page,就会触发磁盘 IO 的操作,它会首先把 dirty page 里面的内容给回写到磁盘作linux同步,再去把该 page 给放到 freelist 里。
下图来看下 memory,page cache,Disk I/O 的关系。


                                            你知道Linux里D进程会搞事吗?

举个简单的例子,比如我们 open 一个文件时,如linux果没有使用 O_DIRECT 这个flag,那就是 File I/O, 所有对磁盘文件的访问都要经过内存,内存会把这部分数据给缓存起来;linux系统安装但是如果使用了 O_DIRECT 这个flag,那就是 Direct I/O, 它会数据废土绕过内存而去直接访问磁盘,访问的这部分数据也不会被缓存起来,自然性能上会降低很多。

page reclaim

在直观上,我们有一个认知,我们现在读了一个文件,它会被缓存到内存里面,如果接下来的一个月我们一直都不会再次访问它,而且数据结构我们这一个月都不会关闭或者重启机器,那么在这一个月之后该文件就不应该再在数据漫游是什么意思内存里头了。
这就是内核对 page cache 的管理策略:LRU(最数据漫游是什么意思近最少使用)。
即把最近最少使用的 page cache 给回收为 free pages。(页框回收算法 PFRA 远没有这么简单)
内核的页回收机制有两种:后台周期性回收和直接回收。
后台回收是有一个内核线程 kswapd 来做,当内存里 free 的 pages 低于一个水位(page_low)时,就会唤醒该内核线程,然后它从 L数据分析RU 链表里回收 page cache 到内存的 free_list系统运维工资一般多少 里头,它会一直回收直至 free 的 pages 达到另外一个水位 page_high 才停止. 如下图所示:


                                            你知道Linux里D进程会搞事吗?

直接回收则是,在发生 page fault/alloc m系统运维工资一般多少emory 时,没有足够可用的内存,于是线程就自己直接去回收内存,它一次性的会回内存回收机制收 32 个 pages。逻辑过程如下图所示:


                                            你知道Linux里D进程会搞事吗?

所以,在内存优化上
1、抬高 watermark 可以间接减少内存回收的并发量,减轻卡在 shrinklinux_inactive_list.
2、提高回收效率,如 LMK 的效率。

然而,还是没彻底解决这个问题,所以我们把疑点再次指向 io。
尝试抓取更多的信息,来了解触linux必学的60个命令发瓶颈的微观过程。
1、数据恢复跑 monkey 增加 io 使用率、io 读写速度监控,以时间片为 100ms,监控连续 D 状态,数据分析师并收集 D 进程堆栈信息、内存信内存回收息等。
2、打开 ftarce 的 vmscan 和 writeback 两个监控点,apk 监控到持续 D 状态就进dump,从 dump 解析 ftrace,再使用 kernelshark 来观察一些数据。

echo 1 > /sys/kernel/debug/tracing/events/writeback/enable  
echo 1 > /sys/kernel/debug/tracing/events/vmscan/enable
echo 1 > /sys/kernel/debug/tracing/tracing_on

为了准备再深入内存回收上述的微观过程,需要再补充一些代码和流程图:


                                            你知道Linux里D进程会搞事吗?


                                            你知道Linux里D进程会搞事吗?

注释的代码不贴了,受微信公众号篇幅限制。

ftrace + kernelshark 辅助分析

执行页面回收中页面状态
ftrace 会抓取下面这些信息统计,所以提前了解下。

struct reclaim_stat {   
unsigned nr_dirty;// page_list中脏页数
unsigned nr_unqueued_dirty;// page_list中脏页但是没有放入块设备请求队列中的页数
unsigned nr_congested;// page_list中阻塞的页数
unsigned nr_writeback; // page_list中处于回写中但是不是被回收的页数
unsigned nr_immediate; //page_list中即回写中而且即将被回收的页数
unsigned nr_activate;// page_list中近期被访问过需要添加到 activate list 的页数
unsigned nr_ref_keep;// page_list中近期被访问过的页数
unsigned nr_unmap_fail;//解除映射失败的页数
};

经过一段时间的老化测试,测试同学终于抓到 log 了。

                                            你知道Linux里D进程会搞事吗?

图中显示 nlinux必学的60个命令r_dirty,nr_congested,nr_linux系统writeback 几乎都是 0,只有零星 nr_activate 被再访问的页面要添加回 active list.

说明现场不存在 dirty 页面很多,回写 io 遇到瓶颈的情况。这个猜想不成立了。

                                            你知道Linux里D进程会搞事吗?

图中显示在 34数据漫游 秒内,所有在 pageoulinux必学的60个命令t() 中的页面,全是 anon 页面,没有 file ?

查看 writeback trace event。

                                            你知道Linux里D进程会搞事吗?

同样,没有很多 writeback 量

从测试结果看到:

1.apk 监控到的 io 使用率不高2.从 ftrace 看到回写量不大

通过最新的数据信息,回到之前的两个大方向:

一是内存紧缺,内存回收不及时,内存需求量大。
LMK 没触发,内存有很多匿名页,都在回收和回写文件页等。
(抬高水位、数据漫游加速 LMK 触发,还有复现,不能彻底解决)
•二是 io 速率慢,某个时间段速率变慢,ufs 频率低,上层读写大量数据,io 占用率过高等。
(数据证明,io 量不多,没有瓶颈)

那么,之前的两个方向猜想,都落空了。那会是什么意想不到的原因?那回去看看卡住的代码,too_many_isolated 代码。

static int __too_many_isolated(struct pglist_data *pgdat, int file, 
struct scan_control *sc, bool stalled)
{
unsigned long inactive, isolated;


if (file) {
if (stalled) {
inactive = node_page_state_snapshot(pgdat,
NR_INACTIVE_FILE);
isolated = node_page_state_snapshot(pgdat,
NR_ISOLATED_FILE);
} else {
inactive = node_page_state(pgdat, NR_INACTIVE_FILE);
isolated = node_page_state(pgdat, NR_ISOLATED_FILE);
}
} else {
if (stalled) {
inactive = node_page_state_snapshot(pgdat,
NR_INACTIVE_ANON);
isolated = node_page_state_snapshot(pgdat,
NR_ISOLATED_ANON);
} else {
inactive = node_page_state(pgdat, NR_INACTIVE_ANON);
isolated = node_page_state(pgdat, NR_ISOLATED_ANON);
}
}




/*
* GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so they
* won't get blocked by normal direct-reclaimers, forming a circular
* deadlock.
*/
if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) == (__GFP_IO | __GFP_FS))
inactive >>= 3;




return isolated > inactive;
}

没有很复杂的逻辑,只有简单的 isolated 和 inactive 统计计数比较。所以,只能是更直接的猜想:
isolated file 统计linux操作系统基础知识一直偏大,导致一数据结构直判断 too_many_isolated 为真,卡在 shrink_inactive_list。
根据这个猜想,从 log 中打印的 mem info,也看到 isolated file 一直偏大,一直在增加,不会减少。好像印证了猜想似的。
LOG:

<6>[95299.607369]  isolated(anon):0kB isolated(file):37880kB  
<6>[95318.568833] isolated(anon):0kB isolated(file):37752kB
<6>[95323.773350] isolated(anon):0kB isolated(file):37752kB
<6>[97520.184804] isolated(anon):0kB isolated(file):44604kB
<6>[97525.658037] isolated(anon):0kB isolated(file):44604kB
<6>[97754.256431] isolated(anon):0kB isolated(file):44604kB
<6>[97759.418172] isolated(anon):0kB isolated(file):44604kB
<6>[97764.574908] isolated(anon):0kB isolated(file):44604kB
<6>[97769.735128] isolated(anon):0kB isolated(file):44604kB
<6>[98543.638667] isolated(anon):0kB isolated(file):44684kB
<6>[98548.905397] isolated(anon):0kB isolated(file):44684kB
<6>[98554.209671] isolated(anon):0kB isolated(file):44684kB
<6>[99996.798031] isolated(anon):0kB isolated(file):51572kB
<6>[100002.122853] isolated(anon):0kB isolated(file):51572kB
<6>[100007.359023] isolated(anon):0kB isolated(file):51572kB
<6>[100146.079882] isolated(anon):0kB isolated(file):51700kB
<6>[100151.313065] isolated(anon):0kB isolated(file):51572kB
<6>[100156.587622] isolated(anon):0kB isolated(file):51572kB
<6>[100328.483071] isolated(anon):0kB isolated(file):51700kB
<6>[100520.245217] isolated(anon):0kB isolated(file):51572kB
<6>[100550.688429] isolated(anon):0kB isolated(file):51572kB
<6>[100555.913634] isolated(anon):0kB isolated(file):51572kB
<6>[100669.226582] isolated(anon):0kB isolated(file):51572kB
<6>[100935.069661] isolated(anon):0kB isolated(file):51688kB
<6>[100940.240279] isolated(anon):0kB isolated(file):51572kB
<6>[100945.476071] isolated(anon):0kB isolated(file):51828kB
<6>[103104.120921] isolated(anon):0kB isolated(file):53344kB
<6>[103121.900214] isolated(anon):0kB isolated(file):53344kB
<6>[103481.197823] isolated(anon):0kB isolated(file):53412kB
<6>[103486.555528] isolated(anon):0kB isolated(file):53412kB
<6>[103721.346234] isolated(anon):0kB isolated(file):53412kB
<6>[103726.655700] isolated(anon):0kB isolated(file):53540kB
<6>[103731.961321] isolated(anon):0kB isolated(file):53540kB
<6>[103737.236295] isolated(anon):0kB isolated(file):53540kB
<6>[103742.470632] isolated(anon):0kB isolated(file):53412kB
<6>[103747.661019] isolated(anon):0kB isolated(file):53284kB
<6>[103752.973978] isolated(anon):0kB isolated(file):53412kB

柳暗花明又一村

对 NR_ISOLATED_FILE/NR_ISOLATED_ANON 的linux是什么操作系统统计增减主要分布在 vmscan.c migrate.c,和 PPR (高通进linux重启命令程内存回收)模块。数据透视表理论上内核 vmscan.c(成双成对) migrate.c 都不会有问题,高通 PPR 模块插入在 vmscan. c 和 task_mmu.c 里,而我们 IMS 没有直linux命令接使用高通 PPR,系统运维工资一般多少嫌疑最大。于是,数据恢复软件免费版在上游确实找到了个相关的 patch。
httpslinux命令://sourcelinux.codeaurlinux重启命令ora.org/quic/la/kernel/msm-4.14/commit/fs/proc/task_mmu.c?h=msm-4.14&id=c800548eac0350391c6d379a89f2e5d4c31366bf
这个 patch 正是修复了 isolated c数据恢复软件免费版ount mismatch 的问题,导致一直让 isolated file 增大。

MADV_FREE clears pte dirty bit and then marks the page lazyfree (clear  
SwapBacked). PPR increments ISOLATE_FILES count, then isolates page and
invokes a reclaim. Inbetween if this lazyfreed page is touched by user then
it becomes dirty. PPR in shrink_page_list in try_to_unmap finds the page
dirty, marks it back as PageSwapBacked and skips reclaim. As PageSwapBacked
set, PPR identifies the page as anon and decrements ISOLATED_ANON, thus
creating isolated count mismatch.


This results in too_many_isolated() check causing delay in reclaim. Skip
reclaiming lazyfreed pages in PPR path.
MADV_FREE (since Linux 4.5) 
The application no longer requires the pages in the range
specified by addr and len. The kernel can thus free these
pages, but the freeing could be delayed until memory pressure
occurs. For each of the pages that has been marked to be
freed but has not yet been freed, the free operation will be
canceled if the caller writes into the page. After a
successful MADV_FREE operation, any stale data (i.e., dirty,
unwritten pages) will be lost when the kernel frees the pages.
However, subsequent writes to pages in the range will succeed
and then kernel cannot free those dirtied pages, so that the
caller can always see just written data. If there is no
subsequent write, the kernel can free the pages at any time.
Once pages in the range have been freed, the caller will see
zero-fill-on-demand pages upon subsequent page references.


The MADV_FREE operation can be applied only to private
anonymous pages (see mmap(2)). In Linux before version 4.12,
when freeing pages on a swapless system, the pages in the
given range are freed instantly, regardless of memory
pressure.
madvise(2) is a system call used by processes to tell the kernel how they are going to use their memory, allowing the kernel to optimize the memory management according to these hints to achieve better overall performance.  


When an application wants to signal the kernel that it isn't going to use a range of memory in the near future, it can use the MADV_DONTNEED flag, so the kernel can free resources associated with it. Subsequent accesses in the range will succeed, but will result either in reloading of the memory contents from the underlying mapped file or zero-fill-on-demand pages for mappings without an underlying file. But there are some kind of apps (notably, memory allocators) that can reuse that memory range after a short time, and MADV_DONTNEED forces them to incur in page fault, page allocation, page zeroing, etc. For avoiding that overhead, other OS like BSDs have supported MADV_FREE, which just mark pages as available to free if needed, but it doesn't free them immediately, making possible to reuse the memory range without incurring in the costs of faulting the pages again. This release adds Linux support for this flag.


Recommended LWN article: Volatile ranges and MADV_FREE

madvise
[
1]系统调用,会建议内核,在从 addr 指定的地址开始,长度等于 len 参数值的范围内,该区域的用户虚拟内存应遵循特定的使用模式,使内核可以选择适当的预读和缓存技术。如果使用 madvise() 函数的程序明确了解其内存访问模式,则使用此函数可以提高系统性能。

自 4.5 开始,引入 MADV_FREE 参数「
这是为什么 4.9 内核才出现该问题,这需系统运维工作内容要上层和底层同时支持,才会出现本问题」。简单来说,MADV_FREE 就是让上层设置一段内存可以释放内存的标志,但是底层并不会立即释数据放,以便让上层可以在短时间内重复访问,以免增加缺页异常等性能开销。也叫 lazy free,它只能用于匿名页面。

根据描述,触发 isolated file 统计增大的路径是:「代码省略不贴」

•上层调用 madvise 系统调用,使用数据废土 MADV_FREE 时,清除 dirty bit 和 SwapBacked bit,把 lazyfree page 加入 inactive file list。
•PPR 增加 ISOLATE_FILES 计数(SwapBac数据废土ked=0),隔离页面并触发回收
•上层访问 lazyfreed 页面,dirty=1
•PPR 执行 reclaim_pte_range -> reclaim_page数据恢复软件免费版s_from_list -> shrink_page_list ->try_to_unmap -> try_to_linux删除文件命令unmap_one 设置 Swaplinux必学的60个命令Backed=1, 并跳出回收
•PPR 继续执行 reclaim_ptelinux是什么操作系统_range -> recla系统运维工程师im_pages_from_linux命令list,putback_lru_数据恢复软件免费版page 的时候,因为 SwapBacked=1,减少了 NR_ISO数据结构LATED_ANON 计数,而不是减少当初增加的 NR_ISOLATED_FILE 计数。
•导致 NR_ISOLATED_FILE 一直被增加

所以,需要在 PPR 中过滤 lazyfree 页面,避免这个 NR_ISOlinuxLATED_FILE 计数异常,导致的卡 too_many_isolatedlinux必学的60个命令
匿名页面一开始就会设置 SwapBacked=1, 并且只有在上层设置 lazyfree 页面时才会清除 ClearPageSwapBacked(page) ,没别的地方了。所以,PageAnon(page) && !PageSwapBacked(page) 能指示这是 lazyfree 页面。

ok,已经理清了前因后果。再退一步,试想下,假如上游没有修复这个 patch。我们能不能想出来?我系统运维工作内容觉得很难,因为我们缺乏 madvise 的相关认识,并且它经过了 dirty, SwapBacked 标志的变化(好像几乎没办法做这么微观的页面标志追踪?),才导致 NR_ISOLATED_ANO系统运维工资一般多少N/FLIE 的变化。

作者吃根辣条

References

​[1]​​madvise:

​​​​​​


                                            你知道Linux里D进程会搞事吗?


                                            你知道Linux里D进程会搞事吗?

扫码或长按关注数据漫游是什么意思
回复
加群

」进入技术群聊