abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 06:00 | Nová verze

Po necelém roce od vydání verze 0.67 byla vydána verze 0.68 populárního telnet a ssh klienta PuTTY. Podrobnosti v přehledu změn. Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
včera 21:32 | Nasazení Linuxu

Canonical představuje nejnovější verzi chytré helmy DAQRI s Ubuntu pro rozšířenou realitu. K vidění bude příští týden v Barceloně na veletrhu Mobile World Congress 2017.

Ladislav Hagara | Komentářů: 0
včera 21:31 | Pozvánky

Pro zájemce o hlubší znalosti fungování operačních systémů připravila MFF UK nový předmět Pokročilé operační systémy, v rámci něhož se vystřídají přednášející nejen z řad pracovníků fakulty, ale dorazí také odborníci ze společností AVAST, Oracle, Red Hat a SUSE. Tento předmět volně navazuje na kurz Operační systémy ze zimního semestru, ale pokud máte praktické zkušenosti odjinud (například z přispívání do jádra Linuxu) a chcete si

… více »
Martin Děcký | Komentářů: 4
včera 21:30 | Pozvánky

Czech JBoss User Group Vás srdečně zve na setkání JBUG v Brně, které se koná ve středu 1. března 2017 v prostorách Fakulty Informatiky Masarykovy Univerzity v místnosti A318 od 18:00. Přednáší Tomáš Remeš a Matěj Novotný na téma CDI 2.0 - New and Noteworthy. Více informací na Facebooku a na Twitteru #jbugcz.

mjedlick | Komentářů: 0
20.2. 23:45 | Zajímavý software

Na blogu Qt bylo představeno Qt 3D Studio. Jedná se o produkt dosud známý pod názvem NVIDIA DRIVE™ Design Studio. NVIDIA jej věnovala Qt. Jedná se o několik set tisíc řádků zdrojového kódu. Qt 3D Studio bude stejně jako Qt k dispozici jak pod open source, tak pod komerční licencí. Ukázka práce s Qt 3D Studiem na YouTube.

Ladislav Hagara | Komentářů: 10
20.2. 17:50 | Komunita

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice slaví 5 let od svého oficiálního vzniku. Nadace byla představena 28. září 2010. Formálně byla založena ale až 17. února 2012.

Ladislav Hagara | Komentářů: 0
20.2. 12:50 | Komunita

Mozilla.cz informuje, že dosud experimentální funkce Page Shot z programu Firefox Test Pilot (zprávička) se stane součástí Firefoxu. Page Shot je nástroj pro vytváření snímků webových stránek. Umí výběr oblasti, prvku stránky (např. odstavce), nebo uložení snímku celé stránky. Snímky lze ukládat na disk nebo nahrávat na server Mozilly. Nedávno bylo oznámeno, že se součástí Firefoxu stane Activity Stream.

Ladislav Hagara | Komentářů: 33
20.2. 04:10 | Nová verze

Po 10 týdnech vývoje od vydání Linuxu 4.9 (zprávička) oznámil Linus Torvalds, mj. již 20 let žijící v USA, vydání Linuxu 4.10 (LKML). Přehled nových vlastností a vylepšení například na Kernel Newbies a v Jaderných novinách (1, 2 a 3). Kódové jméno Linuxu 4.10 je Fearless Coyote.

Ladislav Hagara | Komentářů: 24
19.2. 15:55 | Zajímavý projekt

Vyzkoušet si příkazy a vyřešit několik úkolů lze na stránkách Commandline Challenge (CMD Challenge). Úkoly lze řešit různými způsoby, důležitý je výsledek. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.

Ladislav Hagara | Komentářů: 18
18.2. 17:35 | Bezpečnostní upozornění

Německá Bundesnetzagentur (obdoba českého ČTU) zakázala na německém území prodej panenky Cayla kvůli „špionáži“ dětí. Tato elektronická hračka obsahuje mikrofon, reproduktor a kameru a bezdrátové komunikační rozhraní, pomocí kterého se hračka připojuje na servery výrobce. Takovýmto způsobem může hračka pomocí umělé inteligence „odpovídat“ na dotazy dítěte. Hlavní problém bude ale asi někde jinde, podle prvotních zpráv může

… více »
Petr Tomášek | Komentářů: 34
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (71%)
 (3%)
 (10%)
Celkem 680 hlasů
 Komentářů: 63, poslední dnes 11:29
Rozcestník

Dotaz: Ztracene 2 GiB RAM

21.4.2014 20:43 LinuxakMichal
Ztracene 2 GiB RAM
Přečteno: 1025×
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

21.4.2014 21:24 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
Na základě čeho usuzujete, že se "ztratily"? Není tam integrovaná grafická karta sdílející systémovou paměť?
22.4.2014 06:41 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
Z toho, ze hrube neodpovida mnozstvi fyzicky instalovane pameti v pocitaci s pameti dostupnou pro linux. Je tam diskretni grafika s vlastni pameti.
22.4.2014 07:07 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
Hm… a pořád ještě nemáte pocit, že tahle informace (včetně správné hodnoty) měla být součástí dotazu?
22.4.2014 07:34 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
Hmm, toz pardon. Uvadel jsem, ze chybi zhruba 2 GiB a dal jsem vypis meminfo, kde je videt MemTotal ~126GiB
21.4.2014 23:04 Radek Isa | skóre: 11
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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á.
22.4.2014 06:46 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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).

22.4.2014 01:48 Petr | skóre: 29
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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.
22.4.2014 06:49 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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.
22.4.2014 08:14 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
[ 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.
22.4.2014 08:46 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM

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?

22.4.2014 09:04 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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?
22.4.2014 09:40 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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.
22.4.2014 10:14 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
/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
22.4.2014 10:27 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
00001000-0009e7ff : System RAM
00100000-7df75fff : System RAM
22.4.2014 13:03 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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?
22.4.2014 13:19 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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)).
22.4.2014 14:07 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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.
22.4.2014 14:29 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM

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.

22.4.2014 15:04 LinuxakMichal
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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 ;-)

22.4.2014 15:33 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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ší).
22.4.2014 18:18 alkoholik | skóre: 35 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
Zkuste zapnout HugePages a naalokovat v nich par giga. Jenom ze zvedavosti jestli se zmeni velikost ztracene pameti..
25.4.2014 08:05 Michal2
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM
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 avatar 25.4.2014 14:41 Tomáš Bžatek | skóre: 28 | Brno
Rozbalit Rozbalit vše Re: Ztracene 2 GiB RAM

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.

Koupim litajiciho tucnaka

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.