☰

奇怪的 D 状态进程，可能卡在页面错误处理程序中？

tag-icon • tag-icon linux-kernel
奇怪的 D 状态进程，可能卡在页面错误处理程序中？

我有一个 D 状态进程，但它似乎不在任何系统调用中间。它是一个 CPU 密集型进程 (tensorflow)，并且在另一个 CPU 密集型进程 (bazel) 运行时挂起。以下是一些诊断信息（之后cd /proc/4088）：

➜  4088 uname -a
Linux  4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

➜  4088 sudo cat status
Name:   python3
State:  D (disk sleep)
(output omitted)

➜  4088 sudo cat syscall
-1 0x7ffd69619900 0x7f0bec881390

➜  4088 cat wchan
call_rwsem_down_read_failed%

➜  4088 sudo cat stack
[] call_rwsem_down_read_failed+0x14/0x30
[] __do_page_fault+0x375/0x400
[] do_page_fault+0x22/0x30
[] page_fault+0x28/0x30
[] 0xffffffffffffffff

我还验证了上下文切换计数不会增加。有不dmesg 中有一个可疑条目：

[69396.390301] BUG: unable to handle kernel paging request at ffffea020f767740
[69396.390306] IP: [] mem_cgroup_try_charge+0x2f/0x1e0
[69396.390308] PGD 25edee067 PUD 0 
[69396.390310] Oops: 0000 [#3] SMP 
[69396.390338] Modules linked in: dm_snapshot drbg ansi_cprng ctr ccm pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel uvcvideo kvm snd_hda_codec_hdmi videobuf2_vmalloc videobuf2_memops arc4 videobuf2_v4l2 irqbypass videobuf2_core v4l2_common snd_hda_codec_realtek videodev snd_hda_codec_generic crct10dif_pclmul media crc32_pclmul ghash_clmulni_intel snd_hda_intel aesni_intel snd_hda_codec aes_x86_64 lrw ath9k snd_hda_core nvidia_uvm(POE) gf128mul snd_hwdep glue_helper ath9k_common ablk_helper ath9k_hw cryptd snd_pcm ath snd_seq_midi snd_seq_midi_event mac80211 input_leds joydev snd_rawmidi serio_raw snd_seq cfg80211 snd_seq_device snd_timer rtsx_pci_ms memstick snd mei_me soundcore shpchp mei lpc_ich wmi mac_hid
[69396.390353]  nfsd auth_rpcgss nfs_acl lockd grace sunrpc parport_pc ppdev lp parport autofs4 dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c hid_generic usbhid hid psmouse rtsx_pci_sdmmc i915 nvidia_drm(POE) nvidia_modeset(POE) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(POE) drm ahci alx libahci rtsx_pci mdio video fjes
[69396.390356] CPU: 4 PID: 4176 Comm: python3 Tainted: P      D    OE   4.4.0-62-generic #83-Ubuntu
[69396.390357] Hardware name: Hasee QTC6/HM76, BIOS SR161 02/04/2013
[69396.390358] task: ffff8801d987d400 ti: ffff8801c4bd8000 task.ti: ffff8801c4bd8000
[69396.390362] RIP: 0010:[]  [] mem_cgroup_try_charge+0x2f/0x1e0
[69396.390363] RSP: 0000:ffff8801c4bdbdd0  EFLAGS: 00010246
[69396.390364] RAX: 017fffc000000000 RBX: ffffea0006565140 RCX: ffff8801c4bdbe68
[69396.390365] RDX: 00000000024000c0 RSI: ffff8801d5401400 RDI: ffffea0006565140
[69396.390365] RBP: ffff8801c4bdbe00 R08: ffffffff81cd2dc4 R09: ffffffff81cd2db3
[69396.390366] R10: 0000000000000000 R11: ffffffff81cd2da2 R12: ffffea020f767740
[69396.390367] R13: ffff8801c4bdbe68 R14: 00000000024000c0 R15: ffff8801d5401400
[69396.390369] FS:  00007f0b9d431700(0000) GS:ffff88025f300000(0000) knlGS:0000000000000000
[69396.390370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[69396.390371] CR2: ffffea020f767740 CR3: 000000007c070000 CR4: 00000000001406e0
[69396.390371] Stack:
[69396.390373]  0000000000000000 ffffea0006565140 ffff88020b726640 0000000000000000
[69396.390375]  ffff88020cf7b4d8 00007f0b53600008 ffff8801c4bdbed0 ffffffff811c1e32
[69396.390377]  0000000000000000 0000000000000000 00007f0b9d42fe00 0000000000000001
[69396.390377] Call Trace:
[69396.390382]  [] handle_mm_fault+0x14b2/0x1820
[69396.390386]  [] ? do_futex+0x107/0x540
[69396.390389]  [] ? blk_finish_plug+0x2c/0x40
[69396.390393]  [] ? SyS_madvise+0x48d/0x7d0
[69396.390395]  [] ? __schedule+0x3b6/0xa30
[69396.390398]  [] __do_page_fault+0x197/0x400
[69396.390401]  [] do_page_fault+0x22/0x30
[69396.390404]  [] page_fault+0x28/0x30
[69396.390424] Code: 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 cd 53 48 83 ec 08 0f 1f 44 00 00 49 09 fc 49 89 f7 41 89 d6 48 8b 07 f6 c4 80 75 6c  8b 04 24 f6 c4 40 0f 84 f0 00 00 00 49 8b 04 24 f6 c4 40 0f 
[69396.390427] RIP  [] mem_cgroup_try_charge+0x2f/0x1e0
[69396.390427]  RSP 
[69396.390428] CR2: ffffea020f767740
[69396.390429] ---[ end trace a8c24237c7d97c39 ]---

有趣的是/proc/4088/tasks，除了416841834176

这个问题可能与：https://github.com/bazelbuild/bazel/issues/2445。

为什么会卡住？我能做什么呢？

答案1

导致进程中页面错误的原因是访问当前未映射到 RAM 中的内存位置。除非进程使用 SIGSEGV 处理程序进行肮脏的把戏，否则发生这种情况的原因有两个：它可能是对进程中未映射的地址的访问，在这种情况下进程将崩溃（这是一个错误） ，或者它可以是对已映射但当前不在 RAM 中的地址的访问。后者是完全合法的：它可以是当前不在缓存中的内存映射文件中的位置，或者是当前已换出的已分配内存中的位置。

页面错误意味着该进程导致处理器陷阱（这是访问未映射的内存地址的结果）。陷阱调用内核代码，当该内核代码运行时，进程处于状态 D（不可中断睡眠）。

页面错误导致内核中出现“BUG”。 BUG就是Bug——它不应该发生。此时，进程处于不良状态——内核无法使内存访问工作。系统也处于不良状态，并且根据根本原因，这可能会也可能无法恢复。

日志消息“无法处理 ffffea020f767740 处的内核分页请求”指示进程尝试访问的地址。这是一个核心分页请求，即内核代码处理页面错误时发生的错误。该地址在内核地址范围内。我不擅长分析 Linux 内核错误跟踪来判断问题所在。内核可能已经耗尽了读取进程所需数据所需的某些数据结构的内存。如果这不是问题，请查看您正在使用的内核版本中是否存在任何已知错误。

答案2

只是瞎猜，但是您在该系统上的 NUMA 节点 0 上有内存吗？如果没有，您可能遇到了一个错误。看起来 page_cgroup 可能没有分配给该内存位置。

使用内核参数“cgroup_disable=memory”可能会解决此错误。

相关内容