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
-
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.
-
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.
-
Tak sprcielne na widlich je tohle celkem bezny chovani ... a jmenovat muzu treba diablo 4. Kdyz nemas swap, bude ti zcela bez ohledu na spotrebu ram padat. Staci kdyz toho swapu mas minimalni mnoztvi (tzn stejne se do nej nic nevejde, ale je zaplej) a voiala ...
Co mam jeste v pameti, tak aplikace od adobe ... ty se rovnou odmitaly spustit, klidne i na strojich se stovkama GB ramky.
-
Dokud jsem používal Debian tak jsem SWAP nikdy neměl a nebyl problém.
Po přechodu na Ubuntu jsem musel minimální SWAP vytvořit. Browsery dokázali Ubuntu bez SWAP oddílu po nějaké době zabít, i když RAM jsem měl dostatek, prostě Ubuntu vytuhlo na několik hodin a pokud člověk nechtěl čekat musel resetovat stroj. Jak už někdo podotknul, jsou "programy" které se SWAP oddílem počítají a jak není tak se nechovají jak mají. IMHO to záleží i na systému kde to běží. Jak jsem psal, na Debianu jsem nikdy bez SWAPu nezaznamenal problém, na Ubuntu prakticky okamžitě.
Myslím že jsem tehdy vytvořil 1GB SWAP oddíl a swappiness nastavil na hodnotu 5? Nikdy jsem ve SWAPu neviděl víc jak jednotky MB. -
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.
-
Prave ze delame s PCIe - hw/fpga/drivery.. a alokovat souvislou pamet zvlast uspesne nejde. To co pisete je "teorie". Souvisla pamet se resila v davne dobe pres CMA ( https://lwn.net/Articles/486301/ ) a fungovalo to vicemene tak, ze se nejaka pamet rezervovala pri bootu (default v Kconfig, override pres kernel option):
There is a set of Kconfig options, which specify the default size of the reservation. All of those options are located under “Device Drivers” » “Generic Driver Options” » “Contiguous Memory Allocator” in the Kconfig menu. They allow choosing from four possibilities: the size can be an absolute value in megabytes, a percentage of total memory, the smaller of the two, or the larger of the two. The default is to allocate 16 MiBs.
Tato velikost bylo v podstate exkluzivni carve-out, a neslo tu pamet pouzit jinde.
Od soucasnych DMA zarizeni se opravdu ocekava scatter-gather podpora (tj. nespolehat na souvislou pamet), alternativne na systemu s IOMMU lze souvislou adresaci pro DMA ucely pak emulovat, takze odpada nejaka nutnost reseni problemu s runtime dynamickym CMA.
-
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.
-
Zhruba od jadra 2.6.32 spolupracuji na projektu s vice nez milionem systemu na ruznych platformach, kde se swap nepouziva, a za to dobu doslo k nekolika set OOM situacich, ale nikdy se system nedostal do situace, kdy by z duvodu nedostatku pameti vytuhnul. Jadro samotne odswapovat nejde a je vzdy cele v pameti, takze zde problem byt nemuze. Realisticka moznost by byl bug v OOM notifieru, kam si kazdy ovladac muze zaregistrovat, co chce, ale ten, pokud si dobre pamatuji, v dobe 2.6 kernelu jeste neexistoval. Kazdopadne pokud to jste schopen reprodukovat, doporucuji zapnout NMI watchdog, zreprodukovat a poslat stacktrace, kde system vytuhnul.
-
mam opacnou zkusenost, pokud se prida velmi maly swap, je to cesta jak pocitac kompletne zabit tim ze se uswapuje kdyz se swap zaplni. naopak bez swapu neco proste spadne na oom a je spis klid. takze bud vetsi (aby se cely swap nikdy nezaplnil) nebo radeji zadny.
27. 1. 2026, 08:26 editováno autorem komentáře
-
FíkZlatý podporovatelJe to tak, že hned aktivací swap "ztratíte" nějakou RAM. Nový kód snižuje tuto ztrátu o 30 %. Jsou to malé hodnoty, ale rostou s velikostí swapu. Možná na obrovském swapu už to nebude zanedbatelné.
ČLÁNKY DO MAILU