Một kẻ giết người đáng sợ đang gây trở ngại cho tôi

Tôi không thể hiểu tại sao kernel lại phát hành kẻ giết người oom này khi tôi thấy có đủ bộ nhớ:

Ngoài ra tại sao có rất nhiều trang bộ đệm kernel được phân bổ? Tôi nói đủ bộ nhớ có sẵn sau khi nhìn vào

Bình thường

DMA

Đường miễn phí bình thường

Đây là một thiết bị dựa trên flash nand nhúng với RAM 256 MB

Hạt nhân: 2.6.31

 myshellscript invoked oom-killer: gfp_mask=0xd0, order=2, oomkilladj=0 
 Backtrace: 
 [<c0106494>] (dump_backtrace+0x0/0x110) from [<c03641a0>] (dump_stack+0x18/0x1c) 
 r6:000000d0 r5:c9040c60 r4:00000002 r3:c0448690 
 [<c0364188>] (dump_stack+0x0/0x1c) from [<c015a314>] (oom_kill_process.clone.11+0x60/0x1b4) 
 [<c015a2b4>] (oom_kill_process.clone.11+0x0/0x1b4) from [<c015a738>] (__out_of_memory+0x154/0x178) 
 r8:c21e86e0 r7:001fb000 r6:00000002 r5:000000d0 r4:c9b6e000 
 [<c015a5e4>] (__out_of_memory+0x0/0x178) from [<c015a980>] (out_of_memory+0x68/0xa0) 
 [<c015a918>] (out_of_memory+0x0/0xa0) from [<c015d230>] (__alloc_pages_nodemask+0x42c/0x520) 
 r5:00000002 r4:000000d0 
 [<c015ce04>] (__alloc_pages_nodemask+0x0/0x520) from [<c015d388>] (__get_free_pages+0x18/0x44) 
 [<c015d370>] (__get_free_pages+0x0/0x44) from [<c0109418>] (get_pgd_slow+0x1c/0xe0) 
 [<c01093fc>] (get_pgd_slow+0x0/0xe0) from [<c0129ab0>] (mm_init.clone.43+0xb0/0xf0) 
 r7:c90858c0 r6:00000000 r5:c90858c0 r4:ce1a6680 
 [<c0129a00>] (mm_init.clone.43+0x0/0xf0) from [<c0129c40>] (mm_alloc+0x34/0x44) 
 r6:0009230c r5:c90858c0 r4:ce1a6680 r3:00000000 
 [<c0129c0c>] (mm_alloc+0x0/0x44) from [<c0180f70>] (bprm_mm_init+0x14/0x148) 
 r4:c5154000 r3:cd472564 
 [<c0180f5c>] (bprm_mm_init+0x0/0x148) from [<c01812d0>] (do_execve+0xa8/0x254) 
 [<c0181228>] (do_execve+0x0/0x254) from [<c0106000>] (sys_execve+0x3c/0x5c) 
 [<c0105fc4>] (sys_execve+0x0/0x5c) from [<c0102e80>] (ret_fast_syscall+0x0/0x2c) 
 r7:0000000b r6:0009230c r5:0009237c r4:000922fc 
 Mem-info: 
 DMA per-cpu: 
 CPU 0: hi: 18, btch: 3 usd: 0 
 Normal per-cpu: 
 CPU 0: hi: 42, btch: 7 usd: 0 
 Active_anon:28162 active_file:16 inactive_anon:18037 
 inactive_file:13 unevictable:0 dirty:0 writeback:0 unstable:0 
 free:9998 slab:2447 mapped:164 pagetables:701 bounce:0 
 DMA free:17128kB min:1560kB low:1948kB high:2340kB active_anon:51068kB inactive_anon:10320kB active_file:24kB inactive_file:0kB unevictable:0kB present:97536kB pages_scanned:0 all_unreclaimable? no 
 lowmem_reserve[]: 0 158 158 
 Normal free:22864kB min:2600kB low:3248kB high:3900kB active_anon:61580kB inactive_anon:61828kB active_file:40kB inactive_file:52kB unevictable:0kB present:162560kB pages_scanned:0 all_unreclaimable? no 
 lowmem_reserve[]: 0 0 0 
 DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 17128kB 
 Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 22864kB 
 26591 total pagecache pages 
 0 pages in swap cache 
 Swap cache stats: add 0, delete 0, find 0/0 
 Free swap = 0kB 
 Total swap = 0kB 
 65536 pages of RAM 
 10471 free pages 
 3967 reserved pages 
 2447 slab pages 
 892 shared page count 
 389 shared pages
 620 mapped shared page count
 177 mapped shared pages
 0 pages swap cached
 2481 dma reserved pages
 19892 total user pages
 20512 RSS sum by tasks
 20512 RSS sum by page stats
 164 user cache pages
 26427 kernel cache pages

Chỉnh sửa: Câu trả lời này không chính xác. Mặc dù vẫn có thể là nguyên nhân có thể khiến kẻ giết người oom được gọi, nhưng nó không phải là nguyên nhân trong trường hợp cụ thể này.

Có vẻ như điều này là do sự phân mảnh bộ nhớ.

Từ đầu ra bạn cung cấp, khối bộ nhớ liền kề thứ tự cao nhất bạn có là khối 32kb trong normalvùng. Điều này có nghĩa là nếu bất cứ điều gì cố gắng phân bổ một đoạn bộ nhớ lớn hơn 32kb, nó sẽ thất bại.
Thông thường, điều này không nhất thiết có nghĩa là kẻ giết người oom sẽ được gọi (nếu không, một ứng dụng có thể yêu cầu một khối bộ nhớ lớn và do đó kích hoạt OOM), tuy nhiên đây là hạt nhân đang cố phân bổ bộ nhớ, và vì vậy nó còn hơn một chút nghiêm trọng. Trong trường hợp chính xác này, có vẻ như phân bổ đã được kích hoạt bằng cách bắt đầu một quy trình mới và hạt nhân đang cố phân bổ bộ nhớ cho quy trình đó.

Nhân tự động cố gắng thu gọn bộ nhớ (chống phân mảnh) và có được bộ nhớ liền kề lớn hơn có sẵn, nhưng một số trang không thể được di chuyển. Và hệ thống càng chạy lâu, các trang 'không thể di chuyển' này càng bị phân tán.

Về cơ bản, bạn không thể làm được gì nhiều. Thực sự lựa chọn duy nhất là tiêu diệt các tiến trình để những trang không thể di chuyển đó có thể được giải phóng.

 DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 17128kB 
 Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 22864kB

Một mục giống như 32*16kbcó nghĩa là có 32 khối bộ nhớ liền kề 16kb miễn phí.

Chúng tôi đang xử lý một ứng dụng không xác định trên một nền tảng nhúng không xác định. Rõ ràng, nếu chúng ta có thêm thông tin về hai điểm đó, chúng ta có thể có cơ hội trả lời câu hỏi của abc tốt hơn. Nó cũng sẽ hữu ích để biết chính xác bao nhiêu bộ nhớ mà kịch bản đang cố gắng để có được.

Tôi nghĩ Patrick là chính xác - không đủ DMA liền kề để có thể cho phép quá trình chạy. Điều này có thể là vì những lý do có thể sau đây:

1. Hệ thống nhúng có thể có một triển khai tùy chỉnh phân trang
2. Hệ thống nhúng có thể không có MMU
3. Kịch bản có thể gọi trình điều khiển IO truy cập DMA chính xác
4. Kịch bản có thể chứa các chương trình của bên thứ 3 yêu cầu bộ nhớ liền kề

Vân vân...

Tôi tin rằng nếu bạn giảm phân mảnh bộ nhớ DMA, kẻ giết người OOM sẽ không nhảy. Cách dễ nhất để nhanh chóng kiểm tra đó là khởi động lại thiết bị nhúng và xem liệu kẻ giết người OOM có còn được gọi hay không.

Bây giờ tôi sẽ tiếp tục tìm hiểu trên mạng để tìm kiếm một cách nhẹ nhàng, thân thiện để giải mã bộ nhớ của một người mà không cần thiết lập lại thiết bị của họ.

Liên kết này có thể được quan tâm: http://bl0rg.krunch.be/oom-frag.html