feat(mm): 实现用户态缺页 OOM killer#1984
Conversation
当用户态缺页处理遇到 VM_FAULT_OOM 时，调用 OOM killer 选择并终止 占用内存最多的进程，释放内存后重试缺页，避免系统 livelock。 主要变更： - 新增 kernel/src/mm/oom.rs：OOM killer 核心逻辑，包括进程评分、 选择与终止、内存释放通知与重试等待机制 - 在 AddressSpace 中新增 resident_user_pages 原子计数器，跟踪每个 地址空间的驻留物理页数，作为 OOM 评分的依据 - 缺页处理路径 (fault.rs) 中注入 VM_FAULT_OOM 故障点，并统计新建 present mapping 的页数 - x86_64 page fault handler 中处理 VM_FAULT_OOM：调用 OOM killer 后重试缺页，重试失败则向触发进程发送 SIGKILL - 新增 /proc/sys/vm/oom_fault_inject 调试接口，用于注入 OOM 故障 - 修复 /proc/pid/stat 和 /proc/pid/statm 使用 resident_pages 计数 - 进程退出时通知 OOM 子系统释放地址空间（notify_mm_released） - 新增用户态测试程序 test_oom_killer.c - 新增 OOM killer 设计文档 Signed-off-by: sparkzky <sparkhhhhhhhhhh@outlook.com>
fslongjin
force-pushed
the
feat-oom-killer
branch
from
0c991a5 to
ad214c7
Compare
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad214c7418
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fn current_is_killed_or_exiting() -> bool { | ||
| let current = ProcessManager::current_pcb(); | ||
| Signal::fatal_signal_pending(¤t) || current.flags().intersects(ProcessFlags::EXITING) |
There was a problem hiding this comment.
在已有进程级 SIGKILL 的场景（例如 kill -9，或本 OOM killer 用 PidType::TGID 发送的 SIGKILL）下，信号会进入 sighand.shared_pending；而 Signal::fatal_signal_pending() 只检查当前线程的 sig_pending。因此这里会把已经 doomed 的当前线程当作仍可继续运行，可能在用户缺页 OOM 路径上再次选择并杀死其他 victim，而不是直接返回 CurrentTaskKilled。
Useful? React with 👍 / 👎.
| if score < 0 && !capable(CAPFlags::CAP_SYS_RESOURCE) { | ||
| return Err(SystemError::EACCES); |
There was a problem hiding this comment.
当目标当前已有负的 oom_score_adj（例如父进程或服务管理器设置后子进程降权）时，Linux 语义只要求无 CAP_SYS_RESOURCE 的写入不能进一步降低该值；把值调高（如 -1000 -> -500，减少 OOM 保护）应当允许。这里按 score < 0 拒绝所有负值，会阻止进程减小自己的 OOM 保护，破坏 /proc/[pid]/oom_score_adj 兼容性。
Useful? React with 👍 / 👎.
2 participants
当用户态缺页处理遇到 VM_FAULT_OOM 时，调用 OOM killer 选择并终止
占用内存最多的进程，释放内存后重试缺页，避免系统 livelock。
主要变更：