Vlákno názorů k článku
Jádro bude mít rychlejší swap od Havis 911 - Tak škoda, že sa toto neobjavilo v jadre...

Tak škoda, že sa toto neobjavilo v jadre keď som mal < 2GB RAM :-)
Teraz so 128GB RAM sa swapu (cez zram) jadro ani nedotkne.

Já nedávno zase zápasil s Firefoxem. Na notebooku myslím 16GB nebo 32GB RAM a swap oddíl. Bylo jedno co jsem dělal, swappiness, nastavení paměti Firefoxu, dokonce jsem procesu přes systemd zakázal swapovat. A stejně se mi pořád dělo, že jsem měl zabráno sotva 1/4 RAM, ale ve swapu už smrděly 2GB a Firefox se sotva plazil. Přepnout panel znamenalo přeházet vidlema kupu dat mezi swapem a RAM. A bohužel jsem to nedokázal vyřešit. Na desktopu swap pro jistotu nemám a tam všechno jede perfektně.

Tak škoda, že sa toto neobjavilo v jadre keď som mal < 2GB RAM :-)

V době, kdy byl swap potřeba kvůli tomu, že uživatelé měli málo paměti, by asi ta větší spotřeba paměti mohla být problém.

Na druhou stranu by mne docela zajímalo, kolik uživatelů dnes ještě swap opravdu běžně využívá. Tedy opravdu jako swap, ne jako prostor pro suspend to disk.

Když si chcete hrát s větším LLM, máte dost času, ale RAM jen 128GB, tak se swap hodí, i dnes.

Je mi jasné, že jsou use cases, kde swap potřeba je. Ale docela by mne zajímalo, jak časté to dnes je. A třeba i jak se to vyvíjí v čase.

Lidé mají občas pocit, že to, co dělají oni, dělá "každý". Ale zřídka to tak opravdu je.

Problém je s memory pages, které jsou copy-on-write. Jinými slovy je stránka použitá vícekrát, a pokud do ní někdo zapíše, tak se mu alokuje nová. Tu novou stránku ovšem musíte mít k dispozici. Ve většině případů ji nebudete potřebovat, ale musíte ji mít připravenou. K téhle situaci vedou některá použití mmap (memory mapped files), použití fork() (řekněme duplikace procesu), nebo typicky unixová sekvence fork-exec, která spustí child process pomocí volání fork(), a ten nahradí sebe sama novým procesem pomocí volání exec(). Ve těchto a dalších případech prostě potřebujete mít připravenou paměť, kterou nejspíš nevyužijete, ale pokud dojde na lámání chleba a nebudete ji mít k dispozici, tak nastane problém.

Ve výsledku pokud máte řekněme 128 GB RAM a vypnutý swap, tak část té RAM sedí rezervovaná pro případ potřeby a nepoužije se. Jste potom ve stejné situaci jako kdybyste měl řekněme 96 nebo 64 GB RAM a zapnutý swap.

Pokud jde o výkon, tak minimálně ve Windows se priorita I/O operací při práci se swapem mění podle urgence situace. Například načtení odswapované stránky paměti interaktivní aplikace má prioritu critical, zápis stránek do swapu "pro strýčka příhodu" (ke kterému v případě spousty volné RAM není moc důvod) má nižší prioritu. Ve výsledku tak používání swapu nemá příliš vlivu na výkon, dokud nevyvstane opravdová potřeba swap využívat.

no, my teda zápasíme se swapem ikdyž máme 12x tolik paměti. Zrychlení je určitě správné, protože právě při velkém objemu ten swap dokáže být pěkný prudič.

A tušíte, co je příčina, že to nějak citelně swapuje i v těchto situacích?
Fragmentace paměti, používání hugepages nebo třeba hinting z procesů přes madvise() jako MADV_DONTNEED?
Možná se ptám blbě, ale už dlouho jsem nemusel nic podobného řešit, možná kdysi jsem si někde akorát nastavoval vm.swappiness..

využití paměti nad 80 %, vysoká fragmentace. Holt tisíce java a python procesů udělají svoje. Sice jsou jednotlivé části ze shora omezeny paměti, aby na serveru pořád několik GB na provoz zbylo, tak Linux si začíná swapovat příliš brzy a zvyšuje IO a prodlužuje některé procesy. Většinou to řešíme vypnutím swapu úplně, ale to přináší jiné komplikace.

Díky moc, to dává smysl a speciálně v tomhle měřítku na systému s 1,5 TB RAM a ty optimalizace a ladění jsou důležité. Já jsem byl i zvědavý, jestli nemyslíte něco i v duchu toho, co tu bylo zmíněno výš třeba s tím Firefoxem, že je třeba volná víc jak půlka paměti a přesto systém swapuje.
Osobně, co si vzpomínám na systémy, kde bylo relativně vysoké vytížení paměti a už to šlo místy do kelu (swapu), tak jsem u někoho řešil Proxmox server, ale to nebylo až tak mechanismem swapování, ale špičkami v provozu, kdy spolu občas bojovaly ty virtuály a ZFS (tam je to vždycky trochu alchymie, je za daných podmínek větší benefit v jeho větší ARC nebo bufferování ve vrstvách nad tím). Nakonec se to vyřešilo upravením provisioningu na těch virtuálech, upravením limitů ARC a následně rozšířením paměti.

Jaka je nevyhoda nemit swap v tomto pripade ?

Ja si jenom vsim ze s hodne pameti se poji urcita vleklost.. alokace/dealokace (uprava pagetables) nese dost znatelny overhead. Sice nemame X aplikaci ale treba jedno vlakno vyzadujici desitky GB ram.. tak polechtani stranek na pocatku at se alokuji trva dost dlouho :D

(pro ostatni - zkuste si pustit napr. memtest jako aplikaci.. tam je taky prodleva par vterin na alokaci/dealokaci)

No, jo, jenomže na desktopu tak 95 % lidí nemá tolik paměti ani omylem. Nemluvě o tom, že s těmi 64 GB co tu mám se jádro swapu dotkne zatraceně (i když jen přes zram/zswap) když pustím některé leakující věci. Že je ten software krám je druhá věc ale ten bohužel vyměnit nemohu. A dotknul by se i s dvojnásobkem paměti kdybych ty úlohy prostě velikostně zdvojnásobil (musím je kvůli tomu dělit).

Ja bych treba preferoval FUP popup v UI ... kdyz zacne nejaka aplikace zrat hodne pameti, tak u nejake rozumne miry at vyskoci okno - jako predzvest ze by brzo prisel na radu OOM killer.

Pak ma clovek moznost vzit na vedomi, dat save, close, open a jet odznova.

Jo, paměťová alokace systémem řízené střely: dát tam dvojnásobek paměti, než je potřeba pro dobu letu k cíli, o dealokaci se postará trhavina. ;-D