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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
dnes 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 0
včera 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 16
včera 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 26
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 780 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Ztracene 2 GiB RAM

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