Nevychází nám dal a má dáti? - MujMAC.cz - Apple, Mac OS X, Apple iPod

30. ledna 2003, 00.00 | Minule jsme si vysvětlili, jak je možné, že se někdy přečte více stránek z disku, než se na něj uložilo: pageins může být více, než pageouts. Dnes se podíváme na jinou malou záhadu: pokud si totiž dáte práci posčítat hodnoty v různých sloupcích výpisu služby vm_stat, zjistíte, že "to nevychází".

Minule jsme si vysvětlili, jak je možné, že se někdy přečte více stránek z disku, než se na něj uložilo: pageins může být více, než pageouts. Dnes se podíváme na jinou malou záhadu: pokud si totiž dáte práci posčítat hodnoty v různých sloupcích výpisu služby vm_stat, zjistíte, že "to nevychází".

Skutečně: podívejme se třeba na tentýž příklad, kterým jsme se zabývali minule:

 2 ~> vm_stat 1
 Mach Virtual Memory Statistics: (page size of 4096 bytes, cache hits 78%)
  free active inac wire   faults     copy zerofill reactive  pageins  pageout
  3365  88210 42867 13014  9354203   179958  7655883   161062    13068     8768
  ...

Na první pohled je vidět, že faults (výpadků stránky — případů, kdy nějaký proces "sáhl na adresu", na které nic není) je více, než všech způsobů řešení takového výpadku. Spočítáme-li si to přesně, vychází nám

• výpadků stránky (faults) 9354203;
• kopie stránky byla vytvořena v 179958 případech, nová stránka (zerofill) byla přidělena v 7655883 případech, k reaktivaci stránky již málem odebrané došlo v 161062 případech, a stránka z disku byla načtena v 13068 případech: to je dohromady 8009971;
• zbývá tedy 1344232 výpadků.

Důvody jsou dva. Ten jednodušší — avšak, alespoň za normálních okolností, zodpovědný za menší část "přebytku výpadků" — je prostě to, že ne každý výpadek stránky způsobí její vytvoření! Ve skutečnosti tomu samozřejmě není tak, že proces má k dispozici celý adresový prostor, a může v něm libovolně "řádit", a "kam sáhne, tam se mu vytvoří paměť". Předně, některé úseky adresového prostoru jsou vyhrazené např. pro sdílené knihovny; kromě toho, je z řady důvodů daleko praktičtější, když proces má fakticky k dispozici pouze ty úseky adresového prostoru, o které si nejdřív explicitně řekne. Pokud se proces pokusí pracovat s částí adresového prostoru, do níž má přístup zakázán — ať již zcela, nebo jen zčásti (daný blok je např. určen jen pro čtení, a proces se do něj pokusí zapsat) —, žádná stránka se nepřidělí; namísto toho je proces násilně ukončen.

(Jako zajímavost stojí možná za zmínku to, že v podstatě tentýž mechanismus využívá také ladicí program gdb pro detekci toho, že program použil nějakou proměnnou: v tomto případě sice daný úsek adresového prostoru je procesu přidělen, ale ladicí program úmyslně změní jeho atributy tak, aby při zásahu do něj došlo k výpadku stránky — ten v tomto případě samozřejmě ošetří sám gdb, proces neukončí, ale přeruší, a umožní programátorovi ladění.)

Druhý důvod pro přebytek výpadků nad řešeními spočívá v tom, že Mac OS X je systém multithreadový. Z hlediska uživatele nejsou thready příliš významné, a proto jsme se jim dosud nevěnovali: zjednodušeně řečeno, jde o jakési "procesy uvnitř procesů" — jeden jediný proces může obsahovat několik nezávisle běžících threadů. A v tom je právě jádro pudla: různé thready uvnitř jediného procesu běží zároveň, ovšem pracují se společnou pamětí: vyvolá-li jeden thread výpadek stránky, je samozřejmě pozastaven a čeká, než se stránka přidělí, vynuluje, načte z disku, cokoli... Mezitím ovšem běží ostatní thready; kterýkoli z nich může vyvolat výpadek téže stránky! V takovém případě samozřejmě systém virtuální paměti nic dělat nemusí, jen thread také pozastaví, aby si, spolu s prvním threadem, počkal dokud stránka nebude k dispozici.