0xDEADBEEF

[RSS]
««« »»»

Velké stránky paměti

13. 9. 2017

Transpa­rent Hu­ge­pages: me­a­su­ring the per­for­mance impact

Prak­tická de­mon­strace toho jaký dopad může mít po­vo­lení vel­kých strá­nek paměti.

Ma­po­vání z vir­tu­ální na fy­zic­kou adresu je spra­vo­váno na úrovni strá­nek. Ty na x86 můžou mít ně­ko­lik ve­li­kostí: 4kB, 2MB nebo 1GB. Ope­rační systém udr­žuje toto ma­po­vání v paměti jako stromy (přes­něji řečeno trie). Aby pro­ce­sor ne­mu­sel při každém pří­stupu do paměti pro­chá­zet tímto stro­mem, který je taky v paměti (nebo v lepším pří­padě v cache), ob­sa­huje malou cache na­zý­va­nou TLB (translation loo­kaside buffer) pro ma­po­vání ně­ko­lika na­po­sledy po­u­ži­tých strá­nek. To vede ke stavu, že pokud chci číst ze stránky, která je v TLB, je to rychlé, ale pokud chci číst z té, která tam není, OS musí pro­vést page table walk, najít pří­slušné ma­po­vání, pře­lo­žit adresu a to celou ope­raci značně zpo­malí. Velké stránky byly za­ve­deny z po­cho­pi­tel­ných důvodů: Je jimi možné pokrýt větší část vir­tu­ální paměti a snížit tak počet dra­hých TLB miss.

Od­ka­zo­vaný článek uvádí případ Java apli­kace s 200GB haldou, na které po­vo­lení vel­kých strá­nek vede k ne­za­ne­dba­tel­nému zrych­lení. Pro­gram před změnou trávil 10% taktů jen pře­kla­dem vir­tu­ální adresy na fy­zic­kou a page table walk na­místo uži­tečné práce.

Re­le­vantní čtení:

píše k47 (@kaja47, k47)