Názory k článku
Nový kód pro swap uspoří operační paměť a je rychlejší

Nikdy jsem nepochopil, proc vratit program zpatky do RAM ze swapu trva o tolik dele nez ten program znova spustit (nebo i poprve spustit). Neboli mam pustene dva programy. Prvni je narocny, tak se druhy program presune do swapu. Prvni program skonci, tak chci prepnout na druhy program, zacne se nacitat zpatky ze swapu a trva to priserne dlouho. Trva to mnohem dele nez ten program pustim, klidne poprve po startu OS. Proc? Cekal bych ze nacit jiz hotovou strukturu nacteneho programu do RAM bude primocarejsi nez spustit program s celou jeho inicializaci.
Je to jen moje zkusenost, nedelal jsem zadna korektni mereni, ale setkavam se s tim celkem casto pro ruzne programy (hlavne kdyz prezenu nejaky parametr vypoctu, to pak zahltim RAM driv nez se nadeju).

Protoze kdyz poustite program, tak se viceme pouzije read-ahead, tj. vedome se skryje znamy neduh o pristupovych latencich.

Naproti tomu se ze swapu do RAM dostava kazda page nezavisle a velice sekvencne - az dojde k nutnosti pristoupit na odswapovanou stranku - tak se z disku nacte, pokracuje se v programu.. a on za chvili chce dalsi stranku - takze tam je neskutecne mnohokrat pruchod pres tu dlouhou latenci na disk.

Druhy problem je, ze spusteni programu vyzaduje par mega, desitek mega dat z disku - data/code segmenty z knihoven. Zatimco rozjety program ma naalokovano X stovek mega az jednotky giga pameti.. ktere mohli byt odswapovany.

Zkuste vynutit hugepages, a zjistit zda se nezlepsi rychlost.. pri prechodu z 4K na 2MB se znatelne snizi pocet otocek pres dlouhou latenci.

26. 1. 2026, 20:50 editováno autorem komentáře

a ma smysl pouzivat swap treba pri 64 gb ram?

U serverů s Garbage Collector jazyky ne - odswapování by GC asi zabilo a hlavně se runtime paměť ladí podle celkové velikosti RAM.

U desktopu obvykle taky ne. Já jsem swap vypnul od prvního 16 GB počítače, dneska pro mě výš, ale běžný uživatel si možná s 16 GB stále vystačí. Pokud počítač používá modelování, simulace obtékání, velké numerické výpočty apod, může to být jinak.

PS: Kdysi na pracovním Mac s 16 GB RAM na začátku běžel celkem ok, ale s přibývajícím časem začal příšerně zpomalovat. Jestli to bylo rostoucím software nebo si swapováním odrovnal SSD, těžko říct.

@a6b 26.01.2026 20:52
Některé programy počítají s tím, že swap soubor nebo oddíl existují. Prostá neexistence swapu může způsobit, že se tyto programy začnou chovat nedefinovaně, divně až nepředvídatelně. A nemusí swap vůbec používat. Stačí jeho neexistence.

Celkem by mě zajímalo, jaký to je software – zatím mě tahle situace potkala jen na stroji s FreeDOSem, kde si programy používající JEMM386 po spuštění uštěknou, že nemůžou na disku C: (který není přítomný) vytvořit swap. = )

Na Linuxu se mi tohle ještě nestalo, a to mám hodně velkou tendenci swap nemít.

IMHO se komprimovaný in-memory swap používá třeba na Androidu ke snížení paměťové náročnosti (tuším že se tomu žíká zRAM). Možná má swap i jiné využití. Byl bych opatrný s tím ho považovat za neužitečnou technologii.

Pry bejvavalo za starych casu, ze swap byl potreba pro defragmentaci pameti a bez nej selhavali alokace vetsich souvislych bloku. Ale taky si pamatuji, ze moc sanci vynutit souvisle alokovane bloky nebylo, takze to muze byt jen nejaky hoax, nebo soubeh, ktery si uz nevybavuji.

Jako nejaky swap jsem aktivoval nedavno u instalace na novej disk.. jinak jsem fungoval celkem dlouho bez swapu myslim v pohode. Ale tohle nechapu... proc to zaswapuje 16M kdyz tam je 6.7G volneho :D Asi to pujde zas pryc..

$ free
               total        used        free      shared  buff/cache   available
Mem:        65261068     6280392     6709808     1437768    54437092    58980676
Swap:        6227964       16356     6211608

Souvisle alokované bloky (ve fyzické paměti) jsou potřeba na DMA – už kvůli němu se řeší alokace v několika zónách, protože periferie mohou mít omezení například na 24 (ISA) nebo 32 (±PCI) bitů adresy. Tak nějak bych doufala, že drivery si naalokují buffery dostatečně brzy na to, aby souvislé bloky volné paměti existovaly, ale jistota to není.

Je normální, že si systém odswapuje paměť „napřed“. Pokud toto chování způsobuje problémy, můžete přenastavit vm.swappiness.

zram není specifikum Androidu, je součástí Linuxového jádra. Na současném stroji ho používám, ale občas se mi stává, že se „uswapuje“ a OOM killer nefunguje tak, jak by měl, takže to způsobí zamrznutí.

Možná má swap i jiné využití.

Pokud myslíte zram, tak ten se chová jako blokové zařízení a swap je jen jedním (ikdyž asi nejčastějším) ze způsobů použití.

Od 2.6 (tedy prehistorie) mám vypozorováno, že bez ohledu na velikost RAM, pokud se Linux dostane do OOM situace, tak pokud nemá alespoň malý (16MB stačí swap), tak to často skončí nutností resetu čudlemkdy ani sysrq nepomůže.
Nevím proč tomu je, nezkoumal jsem, prostě těch pár mega to chce, klidně jako loopback fajl.
(hraní se swappines nepomůže)

Naposledy 6.18.1 se 128GB RAM, které zabrala jedna gamesa.