Dotaz: /dev/shm

[daymoon]

Zdravim, k cemu je tenhle shared memory filesystem? Proc je implicitni velikost identicky 1/2 operacni pameti? Muzu ho nejak vyuzit? Muzu ho nejak zabit? (ve fstabu ho nemam, nejaky nestaveni je v /etc/init.d/boot.swap) Diky za info

Odpovědi

[koty]

Virtuální souborový systém shmfs nebo thmfs Systém ho používá mimo jiné k meziprocesorové komunikaci, takže pokud se mohu přimluvit, nezabíjet. Více informací najdete na stránce: http://lwn.net/1998/0409/a/shmfs.html http://lwn.net/2001/1206/a/tmpfs.php3 Jestli Vás zajímá zvětšování a zmenšování, pak doporučuji článeček: http://sdb.suse.de/cz/sdb/html/tmpfs_config.html

[Josef Kufner]

s/meziprocesorové/meziprocesové/

[skywalker]

no linux 2.4 nim realizuje zdielanu pamet, co je forma myslim BSD medziprocesorovej komunikacie, niektore programy ju hojne vyuzivaju. (man shmget, etc) v skutocnosti zabera len tolko, kolko sa jej pouziva, nie viac.

[skywalker]

samozrejme ta ista oprava

[unchallenger]

K předchozím odpovědím bych jen dodal, že existují prasácké programy (např. GAIA), které po sobě sdílenou paměť neuvolňují (což je nutné, dealokace zde automaticky nenastává při ukončení procesu), a pak je to zapotřebí řešit -- buď použitím ipcrm nebo shmclean.

[Agent Smith]

to je proto, ze sdilenou pamet pouzivaji treba na cteni dat z irafu!!! je to nevyhoda techto aplikaci nebot po sobe nemuzou dokonale uklidit proto ze nevi jestli danou pamet stale nepouzivaji jine programy...

[unchallenger]

Blbost. Segment sdílené paměti, který je označen ,,ke smazání`` (v originále destroyed) je skutečně uvolněn až ve chvíli, kdy už ho nikdo nepoužívá. Takže jedině když by GAIA chtěla, aby ten segment něco používalo po jejím skončení, tak by to mělo smysl -- a pak ať si to prasata zařídí, aby se uvolnil alespoň někdy, až ho opravdu nikdo nebude potřebovat.

[unchallenger]

A ještě jsem to napsal blbě. Smysl by to prostě mělo, jen pokud měl existovat okamžik, kdy neběží žádný program používající ten segment a přitom neměl být uvolněn.

[daymoon]

Jestli jde o meziprocesorovou komunikaci a ja mam jenom 1 procesor, tak ho teda s nejvetsi pravdepodobnosti nepotrebuju. Myslim si, ze ho system ani nevyuziva, protoze je porad 0% used. Zkusim mu alespon omezit velikost. Diky za informace

[unchallenger]

to byl překlep. měla to být meziprocesová komunikace

[unchallenger]

df si nevšímej. raději pusť ipcs, a uvidíš (pravděpodobně), že ji něco používá.

[Beda]

hmm... uz mi to pekne dlouho vrta hlavou. aneb linux/Documentation/filesystems/tmpfs.txt

2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
   POSIX shared memory (shm_open, shm_unlink). Adding the following
   line to /etc/fstab should take care of this:

        tmpfs   /dev/shm        tmpfs   defaults        0 0

   Remember to create the directory that you intend to mount tmpfs on
   if necessary (/dev/shm is automagically created if you use devfs).

   This mount is _not_ needed for SYSV shared memory. The internal
   mount is used for that. (In the 2.3 kernel versions it was
   necessary to mount the predecessor of tmpfs (shm fs) to use SYSV
   shared memory)

v cem se vlastne lisi POSIX shm od SYSV shm?
je SYSV sdilena pamet to, ze kdyz se spusti proces, tak jeho stranky nacteny z bloku z disku sou v pameti pro vsechny procesy te same binarky ty samy (a obdobny situace)? kdezto POSIX shm je chapany jako prostredky IPC?
jestli sem se priblizne trefil, tak mi aspon na to kyvnete, jestli ne tam me nakopnete spravnym smerem pls.

[unchallenger]

Hmhmhm, tak že bych nakonec kecal? Ta sdílená paměť, co o ní celou dobu mluvím, co ji vypisuje ipcs, žere GAIA, etc., to je ta SVr4 (co se získává shmget(), a ne shm_open()). Tu fakt programy používají [pro IPC], ale zjevně už nějaký čas není třeba nic nikam mountovat, aby fungovala ;-) Zatímco POSIXové tedy nerozumím, ta vypadá jako něco, co může použít několik procesů k mmapnutí téhož kusu paměti(?)...

[Beda]

vypni si reverzi pri cteni myho postu, teda podle toho co pises to tak vypada, takze to beru jako kyvnuti aspon na tu posix-ipc cast.

[Beda]

sakra beru zpet... mam v tom jeste vetsi mismas, takze zacneme rozdilem shm_get a shm_open. ja vzdy myslel, ze vsechno shm_* a jeste neco vic patri pod posix ipc, je to tak?

[unchallenger]

shm_*() jo ale shmget(), shmat(), shmctl(), ... jsou bez podtržítka a co nemá podtržítko, to je SVr4, a ne POSIX (a tomu snad aspoň trochu rozumím -- vždyť jsem si napsal shmclean...) (teda to podtržítko se týká funkcí, např. u členů struktur to není pravda)

[Beda]

uz to vidim. posix shm_* to sou veci v glibc, takze user space api, kdezto shmget je asi trosku vic low level api, protoze to spada pod api jadra a dohromady to bude asi tak jedno a to samo, ale vyplati se pouzivat posixovy ekvivalenty kvuli prenositelnosti... zeby?

[unchallenger]

no, ve skutečnosti je to v librt, ale to vyjde na stejno ad low-level a high-level: vzhledem k tomu, že shm_open()em vyrábíš jakési jakobysoubory, které stejně vzápětí mmap()neš, protože nechápu, proč bys je jinak vyráběl, tak moc high-level to asi nebude; nicméně mmap() je taky POSIX, takže o tom to asi je... zajímavé je, že (jak píšu níž) jsem nenašel nic, co by používalo shm_open()...

[unchallenger]

já za to vážně nemůžu ;-) raději se zkus tvářit, že to byl překlep, s tou SVr4 je to totiž celkem jisté... a té POSIXové nerozumím (a to jsem si mezitím dvakrát přečetl shm_open(3) a zkusil něco vygooglit...)

[Beda]

to proc si myslis, ze nerozumis posixove je mozna proto, ze ta GAIA cos dal jako priklad praseciho programu neprovede pri skonceni shm_unlink, takze glibc nedostane podnet k tomu, aby zacla zjistovat, ze se ta pamet da uvolnit. man shm_open odstavec pred RETURN VALUE - mozna by glibc prospelo neco jako garbage collection v jave. stejne glibc nekde nad 2.0 + je bloatware ;)

[unchallenger]

pomóc! empirická fakta: 1. když používáš GAIA nějakou dobu, začne řvát vim (např.): Cannot get shared memory segment: : No space left on device (vim nepoužívá shm_open(), ale shmget()) 2. lze se toho zbavit tak, že pomocí ipcrm nebo shmclean uděláš shmctl(id, IPC_RMID, NULL); kde id je id toho segmentu sdílené paměti -- to je to, co GAIA nedělá, takže ty segmenty zůstávají viset i po ukončení a hromadí se jak vidíš, celou dobu tu jde o SVr4 funkce, nikoli o ty POSIXové -- a celkově pochybuji, že by GAIA používala ty POSIXové, které jsou podstatně novější než ona...

[skywalker]

no ja som kecal urcite, lebo sockety su povodom z BSD a teda semafory, shared memory a mutexy su povodom z konkurencneho Unixu - radsej bez mena, aby sme sa urcite vyhli licencnym poplatkom no mmap-nute subory zaberaju pamet, ktoru mozes vo free/top v 2.4 vidiet oznacenu ako cached vo free/top shared memory neni myslim ani jedna z tychto, je to nieco uplne ine a v 2.4 s jednym procesorom to tusim ani neexistuje - vzdy je tam 0 POSIXova shared memory bude urcena na to iste, ako shared memory realizovana jadrom, akurat ze tato je realizovana v user space glibc, aspon to je moj odhad podla tej citacie, ktoru som uz tiez stretol to teda asi bude tak - na kernelom realizovanu shm neni treba ziadny mount v dnesnych casoch, ale kedze prenositelne aplikacie maju byt POSIX kompatibilne, radsej si to tam nechaj

[unchallenger]

počkej, počkej, s procesy a procesory se to snad už vyjasnilo, obojí je prostředek meziprocesové komunikace (sdílení) že nám df u /dev/shm vypisuje všem nulu, znamená buď, že je ten údaj nemá smysl, nebo že se to nepoužívá -- vzhledem k tomu, že jsem nenašel v /usr/bin program, který by dělal shm_open() (zatímco shmget()ujících tam mám řadu), tak i to je možné

[skywalker]

ano, vyjasnili, ja som ani netvrdil nieco ine. nenapisal som to dost jasne - to, co free ukazuje ako shared neni ani jeden tu spominany typ shared memory. je to nieco uplne ine (nejaka kernel tvrdarna), co navyse jadro 2.4 v jednoprocesorovom rezime uz nepouziva urcite, neni som si isty, ci to nahodou nie je nieco, co sa pouziva pri SMP. a to, co vypisuje df pri /dev/shm je nieco uplne ine, nie ta ista 0 ako vo vypise free (/dev/shm je podla uvedenej citovanej poznamky POSIX zdielana pamet realizovana glibc 2.2+). ked je 0 v used pri /dev/shm znamena to teda, ze momentalne ziadny program nepouziva POSIX zdielanu pamet.

[unchallenger]

ok, tak to si rozumíme ta nula u shared ve výstupu free je tam IIRC proto, že ve 2.4 jádře se toho sdílí nějak moc nebo moc složitě a je to těžké pořádně spočítat, takže se na to vykašlali a vypisuje to nulu -- jinak to dřív byly právě ty sdílené knihovny a spol.

[Beda]

kdyz si das ipcs, tak Shared Memory Segments je to co asi dela jak shmget, tak asi i shm_open prenositelnejsim zpusobem s odpovidajicima parametrama, ale shm_open navic dokaze jeste ty semafory, fronty zprav(mutex?)
ad 0 u shared memory, jak v df, tak /proc/meminfo a odpovidajici user space nastroje, ktery to pouzivaj, tak v 2.4 je ta nula u shared docela dlouho. sice ne od zacatku ale po nejake te zmene VMM co byla nekdy ze zacatku. proste je to citelnejsi a rychlejsi kdyz se neudrzuji vselijaky dalsi informace, aby se to dalo spocitat rozumnym zpusobem a nikomu se nechtelo implementovat nejakej silenej pocitaci algoritmus jen proto aby se admin uspokojoval cisilkama kolik usetril vhodnejma programama na pameti ;)

[skywalker]

nie, mutex (mutually exclusive) je semafor a neoddeluje sa na unix od semaforov (vo win32 ano), ktory ma len dve hodnoty. pametal som si, ze su tri sposoby IPC, zabudol som na spravy

[Beda]

monitory - rozsireni zprav+ semaforu+ funkci/metod ve vyssich programovacich jazycich

[Beda]

aha. tak uz mi to asi konecne docvaklo.
sys4/5 nebo jaka pamet (shmget) kterou poskytuje jadro, je normalne oznacena ponekud krytickou informaci, ktera je skoro nepouzitelna, (1)mimo potomky, ktery vzniknou forkem nebo clone, (2)pripadne procesy, ktere nemaji spolecneho predka a pouzivaji jine metody IPC, aby se informovaly o prostredku ipc - sdilenym segmentu, cily skoro hovadina ta dvojka.
kdezto posix tomu pridava namespace, aby dva naprosto nezavisle spusteny procesy mohly pouzivat sdilenou pamet, takze rozsiruje tu dvojku, tak aby se dala rozume pouzit.

snad sem to aspon tedka trefil.

[unchallenger]

otázka je tato: má ta POSIXová sdílená paměť něco společného s SVr4? podle mne nemá, už proto, že ti to jádro každé ukazuje někde úplně jinde takže bych to asi nenazval ,,přidává``, prostě je to nezávislý mechanismus a nikoli nějaký wrapper

[Beda]

souhlas. btw me to jen utvrzuje v tom, ze glibc je bloatware.

[unchallenger]

glibc prostě implementuje všechno, co kdy bylo implementováno na nějakém unixu, plus řadu dalších věcí -- a často celkem užitečných, řekl bych přesně ty funkce, které ve standardní (myslím podle standardu C) libc chybí (např. všechny ty funkce automaticky si [re]alokující buffer akorát tak velký pro výsledek, který vrací), takže si je pak každá lama nemusí bastlit ve svém programu po svém a vyrábět různá buffer overflow... to už ať je to v libc, jednou a pořádně

[Beda]

s/krytickou/kryptickou/