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 14:55 | Komunita

Facebook oznámil, že přelicencuje open source projekty React, Jest, Flow a Immutable.js ze své vlastní kontroverzní licence BSD+Patents na licenci MIT. Stane se tak tento týden s vydáním Reactu 16. Jedním z důvodů přelicencování bylo oznámení nadace Apache, že software pod Facebook BSD+Patents licencí nesmí být součástí produktů pod touto nadací [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Po půl roce od vydání verze 9.0 byla vydána verze 10.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
22.9. 18:11 | Nová verze

Společnost Oracle oficiálně oznámila vydání Java SE 9 (JDK 9), Java Platform Enterprise Edition 8 (Java EE 8) a Java EE 8 Software Development Kit (SDK). Java SE 9 přináší více než 150 nových vlastností.

Ladislav Hagara | Komentářů: 0
22.9. 12:11 | Komunita

Na Humble Bundle lze získat hororovou počítačovou hru Outlast (Wikipedie) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 2
22.9. 10:33 | Humor

Mozilla.cz upozorňuje na Knihu Mozilly (Wikipedie), tj. velikonoční vajíčko ve Firefoxu. Zobrazit jej lze zadáním about:mozilla do adresního řádku. Aktuální verze Firefoxu obsahuje proroctví 15:1 "Dvojčata Mamonu se rozhádala a jejich souboje uvrhly svět do nové tmy. Zvířeti se ale tma hnusila. A tak se stalo mrštnější a silnější, šlo vpřed a jeho počty rostly. A zvíře přineslo oheň a světlo do tmy". Firefox 57 bude obsahovat proroctví 11:14. To je zatím jenom v angličtině. Pomoci lze s překladem do češtiny.

Ladislav Hagara | Komentářů: 10
22.9. 01:22 | Zajímavý projekt
Před měsícem byla spuštěna kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů. Cílem kampaně je vybrat alespoň milion a půl dolarů. Aktuálně je vybráno přes 600 000 dolarů, tj. 40 %. Kampaň poběží ještě další měsíc. Podporu projektu oznámilo KDE i GNOME.
Ladislav Hagara | Komentářů: 34
22.9. 00:55 | Komunita

Agentura DISA (Defense Information Systems Agency) publikovala (pdf) Ubuntu 16.04 Security Technical Implementation Guide (STIG) (zip), tj. doporučené bezpečnostní nastavení Ubuntu 16.04. Ubuntu se tak dostalo mezi unixové operační systémy a linuxové distribuce AIX, HP-UX, Oracle Linux, Red Hat a Solaris [reddit].

Ladislav Hagara | Komentářů: 2
21.9. 22:55 | Bezpečnostní upozornění

CSIRT.CZ informuje, že byly vydány nové bezpečnostní aktualizace, které opravují několik zranitelných míst v Sambě. Útočník může využít zranitelnosti s cílem získání přístupu k potenciálně citlivých informací. Uživatelům a správcům je doporučeno, aby zkontrolovali bezpečnostní opatření pro CVE-2017-12150, CVE-2017-12151 a CVE-2017-12163 a provedli potřebné aktualizace.

Ladislav Hagara | Komentářů: 0
21.9. 21:44 | Komunita

Společnost Red Hat aktualizovala svůj slib ohledně softwarových patentů. Slib nově zahrnuje i open source software pod permisivními licencemi.

Ladislav Hagara | Komentářů: 0
21.9. 08:55 | Komunita

Do 22. září probíhá v Mountain View konference XDC2017 (X.Org Developer's Conference). Na programu je řada zajímavých přednášek. Sledovat je lze online. K dispozici je záznam přednášek ze včerejšího dne.

Ladislav Hagara | Komentářů: 0
Těžíte nějakou kryptoměnu?
 (5%)
 (3%)
 (17%)
 (75%)
Celkem 561 hlasů
 Komentářů: 22, poslední 29.8. 11:23
    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: 29 | 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.