Là bộ nhớ không thể phục hồi được phân bổ cho bản sàn được coi là bộ đệm đã sử dụng hoặc có sẵn?


10

Sau khi đánh giá / Proc / meminfo, tôi thấy các thông tin sau:

$cat /proc/meminfo
MemTotal:       197852592 kB
MemFree:        64755992 kB
MemAvailable:   65655112 kB
Buffers:            4388 kB
Cached:           759952 kB
SwapCached:            0 kB
Active:           649472 kB
Inactive:         308340 kB
Active(anon):     193840 kB
Inactive(anon):    25316 kB
Active(file):     455632 kB
Inactive(file):   283024 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4095932 kB
SwapFree:        4095932 kB
Dirty:                 8 kB
Writeback:             0 kB
AnonPages:        193560 kB
Mapped:            86208 kB
Shmem:             25684 kB
Slab:           49141432 kB
SReclaimable:     667284 kB
SUnreclaim:     48474148 kB
KernelStack:       25600 kB
PageTables:        15152 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    103022228 kB
Committed_AS:    1097276 kB
VmallocTotal:   34359738367 kB
VmallocUsed:    82484800 kB
VmallocChunk:   34126392952 kB
HardwareCorrupted:     0 kB
AnonHugePages:      4096 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      762368 kB
DirectMap2M:    51664896 kB
DirectMap1G:    148897792 kB

Và cụ thể là phiến:

Slab:         46.8651GB
SReclaimable: 0.63637GB
SUnreclaim:   46.2286GB

Sau khi đánh giá slabtop tôi thấy sau đây là người dùng lớn nhất:

      OBJS    ACTIVE  USE OBJ    SIZE   SLABS  OBJ/SLAB  CACHE SIZE                    NAME
  10855309  10855309     100%   1.07K  374321        29      11.42G         zfs_znode_cache
  10893059  10893059     100%   0.85K  294407        37       8.98G                 dnode_t
    412694    410756      99%  16.00K  206347         2       6.30G           zio_buf_16384
  12502304  12290111      98%   0.50K  390697        32       5.96G             kmalloc-512
  12776610  12744002      99%   0.29K  232302        55       3.54G          dmu_buf_impl_t
  10855309  10855309     100%   0.27K  374321        29       2.86G                sa_cache
    370776    370718      99%   8.00K   92694         4       2.83G            kmalloc-8192
   3269280   3028688      92%   0.32K   66720        49       1.02G               taskstats
  10899924  10899924     100%   0.08K  213724        51       0.82G  selinux_inode_security
  12161408  12150615      99%   0.06K  190022        64       0.72G              kmalloc-64
   3266592   3266072      99%   0.19K   77776        42       0.59G                  dentry
   5577600   5519569      98%   0.09K  132800        42       0.51G              kmalloc-96
     92872     82422      88%   4.00K   11609         8       0.35G            kmalloc-4096
   1962464   1953555      99%   0.12K   61327        32       0.23G             kmalloc-128
   6022528   6022428      99%   0.03K   47051       128       0.18G              kmalloc-32
      8356      8346      99%  12.00K    4178         2       0.13G           zio_buf_12288

Điều gì làm cho bộ nhớ phiến có thể phục hồi so với không thể phục hồi? "Không thể phục hồi" nghĩa là gì khi hệ thống cần phân bổ và không có đủ bộ nhớ? Có linh hoạt như buff / cache không?

Câu trả lời:


1

Bộ nhớ SLAB có thể phục hồi có thể được sử dụng lại bởi kernel cho những thứ khác, không thể phục hồi được. Trường hợp bất kỳ phân bổ SLAB cụ thể nào kết thúc được hạch toán tùy thuộc vào các thuộc tính của nhóm được phân bổ, điều đó có nghĩa là đó là một thuộc tính của chính phân bổ đó.

Hơi OT, nhưng với giá trị của nó, khối lượng lớn bộ nhớ SLAB không thể nhận được có lẽ là ZFS ARC.


Vì đây là một câu hỏi rất kỹ thuật, bạn có thể cung cấp trích dẫn cho câu trả lời của bạn không?
Zhro

Chắc chắn, nhưng có lẽ sẽ lâu thôi, vì tôi sẽ phải tìm kiếm thông qua mã hạt nhân để tìm các bit liên quan đến điều này (thật không may là không có tài liệu nhiều ở bất cứ đâu và kiến ​​thức của tôi chủ yếu dựa vào kiểm tra mã) .
Austin Hemmelgarn

@AustinHemmelgarn đã được một lúc và tôi cũng quan tâm.
Gregg Leventhal
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.