Dotaz: Ztracene 2 GiB RAM

[LinuxakMichal]

Zdravim, nekam se mi ztrtatily cca 2 GiB fyzicke pameti.
Linux kubuntu1404 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Meminfo:

MemTotal:       132003196 kB
MemFree:        120722048 kB
Buffers:          157348 kB
Cached:          8189884 kB
SwapCached:            0 kB
Active:          3702184 kB
Inactive:        6132636 kB
Active(anon):    1492308 kB
Inactive(anon):   124568 kB
Active(file):    2209876 kB
Inactive(file):  6008068 kB
Unevictable:          64 kB
Mlocked:              64 kB
SwapTotal:      134182908 kB
SwapFree:       134182908 kB
Dirty:                 4 kB
Writeback:             0 kB
AnonPages:       1487788 kB
Mapped:           521012 kB
Shmem:            129292 kB
Slab:             464380 kB
SReclaimable:     376508 kB
SUnreclaim:        87872 kB
KernelStack:        7296 kB
PageTables:        50072 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    200184504 kB
Committed_AS:    5185008 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      563156 kB
VmallocChunk:   34290997244 kB
HardwareCorrupted:     0 kB
AnonHugePages:    583680 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      370136 kB
DirectMap2M:    11130880 kB
DirectMap1G:    124780544 kB

/proc/mtrr

reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg02: base=0x200000000 ( 8192MB), size= 8192MB, count=1: write-back
reg03: base=0x400000000 (16384MB), size=16384MB, count=1: write-back
reg04: base=0x800000000 (32768MB), size=32768MB, count=1: write-back
reg05: base=0x1000000000 (65536MB), size=65536MB, count=1: write-back
reg06: base=0x2000000000 (131072MB), size= 2048MB, count=1: write-back

Uryvek dmesg:

[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask 3FE000000000 write-back
[    0.000000]   1 base 002000000000 mask 3FFF80000000 write-back
[    0.000000]   2 base 000080000000 mask 3FFF80000000 uncachable
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000]   8 disabled
[    0.000000]   9 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] original variable MTRRs
[    0.000000] reg 0, base: 0GB, range: 128GB, type WB
[    0.000000] reg 1, base: 128GB, range: 2GB, type WB
[    0.000000] reg 2, base: 2GB, range: 2GB, type UC
[    0.000000] total RAM covered: 131072M
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000]  gran_size: 64K  chunk_size: 64K         num_reg: 7      lose cover RAM: 0G
[    0.000000] New variable MTRRs
[    0.000000] reg 0, base: 0GB, range: 2GB, type WB
[    0.000000] reg 1, base: 4GB, range: 4GB, type WB
[    0.000000] reg 2, base: 8GB, range: 8GB, type WB
[    0.000000] reg 3, base: 16GB, range: 16GB, type WB
[    0.000000] reg 4, base: 32GB, range: 32GB, type WB
[    0.000000] reg 5, base: 64GB, range: 64GB, type WB
[    0.000000] reg 6, base: 128GB, range: 2GB, type WB
[    0.000000] e820: update [mem 0x80000000-0xffffffff] usable ==> reserved
[    0.000000] e820: last_pfn = 0x7df76 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000fdc20-0x000fdc2f] mapped at [ffff8800000fdc20]
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
[    0.000000] Using GB pages for direct mapping
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x01fdd000, 0x01fddfff] PGTABLE
[    0.000000] BRK [0x01fde000, 0x01fdefff] PGTABLE
[    0.000000] BRK [0x01fdf000, 0x01fdffff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x207fe00000-0x207fffffff]
[    0.000000]  [mem 0x207fe00000-0x207fffffff] page 1G
[    0.000000] init_memory_mapping: [mem 0x207c000000-0x207fdfffff]
[    0.000000]  [mem 0x207c000000-0x207fdfffff] page 1G
[    0.000000] init_memory_mapping: [mem 0x2000000000-0x207bffffff]
[    0.000000]  [mem 0x2000000000-0x207bffffff] page 1G
[    0.000000] init_memory_mapping: [mem 0x1000000000-0x1fffffffff]
[    0.000000]  [mem 0x1000000000-0x1fffffffff] page 1G
[    0.000000] init_memory_mapping: [mem 0x00100000-0x7df75fff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0x7ddfffff] page 2M
[    0.000000]  [mem 0x7de00000-0x7df75fff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0xfffffffff]
[    0.000000]  [mem 0x100000000-0xfffffffff] page 1G

Je to tim regionem 2 typu uncachable? Jeste podotknu, ze ve windows na identickem HW takovy problem neni. Take si matne vzpominam, ze na Ubuntu 12.04 to take nedelalo. Ma nekdo napad, jak to opravit?

Odpovědi

[Michal Kubeček]

Na základě čeho usuzujete, že se "ztratily"? Není tam integrovaná grafická karta sdílející systémovou paměť?

[LinuxakMichal]

Z toho, ze hrube neodpovida mnozstvi fyzicky instalovane pameti v pocitaci s pameti dostupnou pro linux. Je tam diskretni grafika s vlastni pameti.

[Michal Kubeček]

Hm… a pořád ještě nemáte pocit, že tahle informace (včetně správné hodnoty) měla být součástí dotazu?

[LinuxakMichal]

Hmm, toz pardon. Uvadel jsem, ze chybi zhruba 2 GiB a dal jsem vypis meminfo, kde je videt MemTotal ~126GiB

[Radek Isa]

Me napadaji tyhle moznosti. paměť más nekde namapovanou na disk, nebo pro jine periferni zařízení s přímím přístupep do paměti. dalsi moznost, ktera me napade je že jsi rozdělaval komp a poradne jsi nezacvakl tu ram paměť nebo odešla do věčných lovišť. I když tu hardwarovou stranku bych asi vyloučil vzhledem k tomu že ti to na widlích běhá.

[LinuxakMichal]

Lze nejak zjistit, ktere zarizeni by si mohlo uzurpovat tolik pameti? HW stranku bych take vyloucil, kdyby jeden modul chybel, nevidel by ho ani BIOS a navic nesedi velikost (mam 8 kusu 16GB modulu).

[Petr]

Zkusil bych se nejprve podivat co rika BIOS a pak to projit Memtestem.. Podle vysledku pak postupovat dal. Pripadne nejaky livelinux a podivat se z nej.

[LinuxakMichal]

BIOS vidi v poradku vsech 128GB pameti, memtestem to proslo nedavno take ok. Testnu jeste ubuntu 12.04 ale jak rikam, v nem jsem si problemu nevsiml takze tam bude dostupna na 90 % viditelna cela pamet.

[LinuxakMichal]

[ 0.000000] Memory: 131974008K/134184012K available (7338K kernel code, 1138K rwdata, 3388K rodata, 1332K init, 1440K bss, 2210004K reserved)

Odpoved bude asi nekde tady:

[ 0.000000] BIOS-e820: [mem 0x0000000080000000-0x000000008fffffff] reserved potazmo [ 0.000000] e820: update [mem 0x80000000-0xffffffff] usable ==> reserved

velikost odpovida 2 GiB. Ovsem co to zpusobuje se mi nedari dohledat.

[Michal Kubeček]

V tom by nutně problém být nemusel:

[    0.000000] reg 0, base: 0GB, range: 2GB, type WB
[    0.000000] reg 1, base: 4GB, range: 4GB, type WB
[    0.000000] reg 2, base: 8GB, range: 8GB, type WB
[    0.000000] reg 3, base: 16GB, range: 16GB, type WB
[    0.000000] reg 4, base: 32GB, range: 32GB, type WB
[    0.000000] reg 5, base: 64GB, range: 64GB, type WB
[    0.000000] reg 6, base: 128GB, range: 2GB, type WB

Tyhle 2 GB by tedy jen měly být přemapované na konec. Nemáte to oříznuté parametrem mem?

[LinuxakMichal]

Ne, mem parametr jadru nepredavam:

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=22a84444-94a3-4443-ad47-d5d52937584d ro quiet splash

Pri googlovani jsem prosel uz par desitek vypisu a usuzuji, ze mezi velikosti pameti a velikosti reserved je velmi silna korelace. Neni v te pameti schovana nejaka jaderna struktura? Treba pamet rezervovana pro page tables nebo tak neco?

[Michal Kubeček]

Na x86_64 má PTE 64 bitů, takže při 128 GB (virtuální) paměti potřebujete 256 MB (plus něco málo na vyšší úrovně). Interní struct page má 48 MB, což by už sice dalo 1536 MB, ale vmemmap se IIRC počítá do MemTotal.

[LinuxakMichal]

/proc/iomem :

00000000-00000fff : reserved
00001000-0009e7ff : System RAM
0009e800-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000dffff : PCI Bus 0000:00
  000c0000-000ce9ff : Video ROM
  000cf000-000cf3ff : Adapter ROM
  000cf800-000d07ff : Adapter ROM
000e0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-7df75fff : System RAM
  01000000-0172abb4 : Kernel code
  0172abb5-01d1c9bf : Kernel data
  01e74000-01fdbfff : Kernel bss
7df76000-7e0e0fff : reserved
  7df86018-7df8603e : APEI ERST
  7df8603f-7df8803e : APEI ERST
7e0e1000-7e2f1fff : ACPI Non-volatile Storage
7e2f2000-7f353fff : reserved
7f354000-7f7fffff : ACPI Non-volatile Storage
7f800000-7fffffff : RAM buffer
80000000-dfffffff : PCI Bus 0000:00
  80000000-8fffffff : PCI MMCONFIG 0000 [bus 00-ff]
    80000000-8fffffff : reserved
  d0000000-d9ffffff : PCI Bus 0000:04
    d0000000-d7ffffff : 0000:04:00.0
    d8000000-d9ffffff : 0000:04:00.0
  da400000-da8fffff : PCI Bus 0000:05
    da400000-da7fffff : 0000:05:00.0
      da400000-da7fffff : isci
    da800000-da87bfff : 0000:05:00.0
    da87c000-da87ffff : 0000:05:00.0
      da87c000-da87ffff : isci
  daa00000-daafffff : PCI Bus 0000:06
    daa00000-daa1ffff : 0000:06:00.1
    daa20000-daa3ffff : 0000:06:00.1
    daa40000-daa5ffff : 0000:06:00.0
    daa60000-daa7ffff : 0000:06:00.0
  de000000-df0fffff : PCI Bus 0000:04
    de000000-deffffff : 0000:04:00.0
      de000000-deffffff : nvidia
    df000000-df07ffff : 0000:04:00.0
    df080000-df083fff : 0000:04:00.1
      df080000-df083fff : ICH HD audio
  df100000-df1fffff : PCI Bus 0000:0a
    df100000-df103fff : 0000:0a:02.0
    df104000-df1047ff : 0000:0a:02.0
      df104000-df1047ff : firewire_ohci
  df200000-df2fffff : PCI Bus 0000:09
    df200000-df201fff : 0000:09:00.0
      df200000-df201fff : xhci_hcd
  df300000-df3fffff : PCI Bus 0000:08
    df300000-df301fff : 0000:08:00.0
      df300000-df301fff : xhci_hcd
  df400000-df4fffff : PCI Bus 0000:06
    df400000-df41ffff : 0000:06:00.1
      df400000-df41ffff : igb
    df420000-df43ffff : 0000:06:00.0
      df420000-df43ffff : igb
    df440000-df443fff : 0000:06:00.1
      df440000-df443fff : igb
    df444000-df447fff : 0000:06:00.0
      df444000-df447fff : igb
  df500000-df5fffff : PCI Bus 0000:05
  df600000-df603fff : 0000:00:1b.0
    df600000-df603fff : ICH HD audio
  df604000-df607fff : 0000:00:04.7
    df604000-df607fff : ioatdma
  df608000-df60bfff : 0000:00:04.6
    df608000-df60bfff : ioatdma
  df60c000-df60ffff : 0000:00:04.5
    df60c000-df60ffff : ioatdma
  df610000-df613fff : 0000:00:04.4
    df610000-df613fff : ioatdma
  df614000-df617fff : 0000:00:04.3
    df614000-df617fff : ioatdma
  df618000-df61bfff : 0000:00:04.2
    df618000-df61bfff : ioatdma
  df61c000-df61ffff : 0000:00:04.1
    df61c000-df61ffff : ioatdma
  df620000-df623fff : 0000:00:04.0
    df620000-df623fff : ioatdma
  df624000-df624fff : 0000:00:1f.6
  df625000-df6250ff : 0000:00:1f.3
  df626000-df6267ff : 0000:00:1f.2
    df626000-df6267ff : ahci
  df627000-df6273ff : 0000:00:1d.0
    df627000-df6273ff : ehci_hcd
  df628000-df6283ff : 0000:00:1a.0
    df628000-df6283ff : ehci_hcd
  df62a000-df62a00f : 0000:00:16.1
  df62b000-df62b00f : 0000:00:16.0
  df62c000-df62cfff : 0000:00:05.4
  dfffc000-dfffcfff : dmar1
e0000000-fbffffff : PCI Bus 0000:80
  fbf00000-fbf03fff : 0000:80:04.7
    fbf00000-fbf03fff : ioatdma
  fbf04000-fbf07fff : 0000:80:04.6
    fbf04000-fbf07fff : ioatdma
  fbf08000-fbf0bfff : 0000:80:04.5
    fbf08000-fbf0bfff : ioatdma
  fbf0c000-fbf0ffff : 0000:80:04.4
    fbf0c000-fbf0ffff : ioatdma
  fbf10000-fbf13fff : 0000:80:04.3
    fbf10000-fbf13fff : ioatdma
  fbf14000-fbf17fff : 0000:80:04.2
    fbf14000-fbf17fff : ioatdma
  fbf18000-fbf1bfff : 0000:80:04.1
    fbf18000-fbf1bfff : ioatdma
  fbf1c000-fbf1ffff : 0000:80:04.0
    fbf1c000-fbf1ffff : ioatdma
  fbf20000-fbf20fff : 0000:80:05.4
  fbffe000-fbffefff : dmar0
fc000000-fcffffff : pnp 00:00
fd000000-fdffffff : pnp 00:00
fe000000-feafffff : pnp 00:00
feb00000-febfffff : pnp 00:00
fec00000-fec003ff : IOAPIC 0
fec01000-fec013ff : IOAPIC 1
fec40000-fec403ff : IOAPIC 2
fed00000-fed003ff : HPET 0
fed08000-fed08fff : pnp 00:0a
fed0e000-fed0ffff : PCI Bus 0000:00
fed1c000-fed3ffff : reserved
  fed1c000-fed1ffff : pnp 00:0a
    fed1f410-fed1f414 : iTCO_wdt
fed45000-fedfffff : pnp 00:00
fee00000-fee00fff : Local APIC
ff000000-ffffffff : reserved
  ff000000-ffffffff : pnp 00:0a
100000000-207fffffff : System RAM

100000000-207fffffff : System RAM => 126 GiB i tady ty 2 GiB hapruji. Ale nikde naznak, kampak se ztratily

[Michal Kubeček]

00001000-0009e7ff : System RAM
00100000-7df75fff : System RAM

[LinuxakMichal]

Pravda, nevsiml jsem si. Vracim se k teorii s datovou strukturou jadra. Konkretne mem_map neboli seznam mem_map_t se inicializuje pri bootu a mel by obsahovat zaznam pro vsechny fyzicke stranky. Koukam, ze v aktualnim jadre by ta struktura mela mit 98 bajtu. Jenze to je zase vice nez schazejicich 2 GiB (pri 33554432 4KiB strankach), vychazelo by to pri 64 bajtech

Take nemuzu dohledat, zda je tato pamet v reserved nebo v memtotal casti... Vetsi smysl by mi davalo reserved pac to je struktura staticka (pokud pominu nejaky hotplug pameti), skoro jiste nejde odswapnout.

Muze tam hrat nejakou roli, ze se jedna de facto o NUMA?

[Michal Kubeček]

Nerozumím. Jediné místo, kde se v aktuálních zdrojácích jádra vyskytuje "mem_map_t" (ne jako substring), je Documentation/virtual/uml/UserModeLinux-HOWTO.txt. Proměnná mem_map je pointer na struct page a k těm už jsem se vyjadřoval výše (jen jsem se přehlédl, na x86_64 má 56 B, ne 48 (ale rozhodně ne 98)).

[LinuxakMichal]

Tak to ovsem koukam, ze info v LDT je neplatne: http://www.tldp.org/LDP/tlk/ds/ds.html protoze to na 56 bajtu nevypada. Dohledal jsem to teda v aktualnim jadre ( https://github.com/torvalds/linux/blob/master/include/linux/mm_types.h ) a zjistil, ze pocitat tu velikost je dosti netrivialni, budu ti tedy verit, ze to je 56 bajtu.

Pokusim se zjistit, zda tato struktura je v memtotal.

[Michal Kubeček]

To vypadá hodně staře… Tohle je OpenSuSE 12.3 (jádro 3.7), ale podobné to bude na většině aktuálních distribucí:

crash> struct -o page
struct page {
   [0] unsigned long flags;
   [8] struct address_space *mapping;
       struct {
           union {
  [16]         unsigned long index;
  [16]         void *freelist;
  [16]         bool pfmemalloc;
           };
           union {
  [24]         unsigned int counters;
               struct {
                   union {
  [24]                 atomic_t _mapcount;
                       struct {
  [24]                     unsigned int inuse : 16;
  [24]                     unsigned int objects : 15;
  [24]                     unsigned int frozen : 1;
                       };
  [24]                 int units;
                   };
  [28]             atomic_t _count;
               };
           };
       };
       union {
  [32]     struct list_head lru;
           struct {
  [32]         struct page *next;
  [40]         int pages;
  [44]         int pobjects;
           };
  [32]     struct list_head list;
           struct {
  [32]         struct kmem_cache *slab_cache;
  [40]         struct slab *slab_page;
           };
       };
       union {
  [48]     unsigned long private;
  [48]     spinlock_t ptl;
  [48]     struct kmem_cache *slab;
  [48]     struct page *first_page;
       };
}
SIZE: 56

Pokusim se zjistit, zda tato struktura je v memtotal.

Vypadá to, že stránky s vmemmap jsou reserved, takže by se do MemTotal počítat neměly. Ale jestli chcete, najděte si to v kódu.

[LinuxakMichal]

Na to nemam, rozhodl jsem se pro empiricky pruzkum. Udlelal jsem virtualni stroj abych s tim mohl snadno experimentovat.

Na 1 GiB pameti je reserved 56212 KiB, na 2 GiB pameti je reserved 72600 KiB, na 3 GiB pameti je reserved 88988KiB. Tedy pridanim 1 GiB pameti naskoci reserved o 16388 KiB. To je necelych 64 bajtu na kilobajt neboli

128*16388 KiB = 2048.5 MiB tedy neco malo pres 64 bajtu na stranku. Treba se polozky v te strukture zarovnavaji na 64 bajtove hranice aby byly cele v jedne cache line. Nebo tak neco. Uz to dale neresim

Case closed, neni to bg, je to vlastnost

[Michal Kubeček]

Nezarovnávají, je to pole. Ale je možné, že u vás je struct page o kousek větší. Nebo bych spíš odhadoval, že to není jediná reserved oblast (jen největší).

[alkoholik]

Zkuste zapnout HugePages a naalokovat v nich par giga. Jenom ze zvedavosti jestli se zmeni velikost ztracene pameti..

[Michal2]

Otestovano, nezmeni se nic.

Dost by me zajimalo, jak se to chova pri hotplugu pameti ale na to nemam HW. To by se dalo otestovat asi jen pres hypervirtualizaci XEN nebo KVM, kde pridavat a odebirat pamet za chodu virtualni masiny lze.

[Tomáš Bžatek]

Mozna by pomohlo pouzit EFI boot, kde se pametova mapa sestavuje jinak (viz. take parametr jadra "add_efi_memmap") a prip. si pohrat s MTRR cleanupem (parametr jadra "mtrr-cleanup"), ale stejne jsem k tomu skepticky.