Linux KSM memory deduplikering

[lath]

Kernen kan noget smart, og det hedder: "Linux KSM memory deduplikering" - og hvad betyder det så?

Først skal vi lige have nogle begreber på plads (simplificerede forklaringer):

• page: en sammenhængende blok af hukommelse på (oftest) 4 KB (=4096 bytes). Der er pages i fysisk RAM, swap, og så virtuel hukommelse.
  Virtuel hukommelse består af hukommelse fra fysisk RAM og swap + en liste af pages inde i kernen.
• copy-on-write: Når mere end 1 program (processer) eller 1 library deler den samme page, og den page er markeret copy-on-write, så laver kernen en kopi af en page, hvis et program begynder at skrive til den page. Når kernen er færdig med at kopiere har de 2 programmer en forskellig page, som indeholder indholdet af den page de før delte. Derefter gentager kernen maskinkodeinstruktionen for det program der ville skrive til copy-on-write pagen, og denne gang lykkedes skrivningen så for programmet, da den skriver til sin egen page.

Linux KSM memory deduplikering betyder at kernen kan finde 2 ens (som i nøjagtig ens) pages.
Kernen laver så 2 ændringer i sin liste over pages:

• Den lader den ene af de 2 pages pege på den anden page, og markerer den nu delte page for en copy-on-write page.
• Den lader den anden page markeres som fri hukommelse

Det betyder at hvis kernen kan finde - lad os sige - 1025 ens pages vil det resultere i at 1024 pages bliver til fri hukomelse (det er 4 MB, hvis 1 page= 4KB), og at den ene page vil så blive delt 1025 gange.
(ekstrem sammenligning, men det fremmer måske forståelsen).

Læs mere:

• https://en.wikipedia.org/wiki/Kernel_same-page_merging
• https://insights.ubuntu.com/2015/05/18/lxd-crushes-kvm-in-density-and-speed
• http://www.iron.io/blog/2013/03/how-we-went-from-30-servers-to-2-go.html

/Lars

[AJenbo]

Det lyder som om den største fordel ville være ved virtuelle host maskiner hvor den samme stack er indlæst flere gange (1 for hver klient maskine). Kender du nogle yderligere måliger af hvad det har af konsekvenser for eks en desktop maskine?

[lath]

Det lyder som om den største fordel ville være ved virtuelle host maskiner hvor den samme stack er indlæst flere gange (1 for hver klient maskine). Kender du nogle yderligere måliger af hvad det har af konsekvenser for eks en desktop maskine?

Konsekvenser for eks en desktop maskine er at kun et lib*.so bibliotek eller et program - efter noget tid - er indlæst nøjagtig en gang i den virtuelle hukommelse, hvis, og kun hvis, de er identiske binært.

Overnævnte gælder ikke JVM (Java), Mono (.NET), Node.js, og lign. programmer, da de ændrer i maskinkode instruktionerne under udførelsen af programmet (JIT kompilering af bytecode/et AST).

/Lars

[AJenbo]

Jo det forstår jeg. Det har dog stadig have en vis effekt for jit og script sprog, især hvis der er opcode cache. .NET compiler vist dele af programmet og gemmer det på disken, jeg ville forvente at Mono gør noget af det samme.

Ville nu gerne se tal for ydelse og ram forbrug.

[lath]

Jo det forstår jeg. Det har dog stadig have en vis effekt for jit og script sprog, især hvis der er opcode cache. .NET compiler vist dele af programmet og gemmer det på disken, jeg ville forvente at Mono gør noget af det samme.

Ville nu gerne se tal for ydelse og ram forbrug.

Jeg fandt noget at kigge på her:

• http://kerneldedup.org/en/projects/uksm/benchmarks/
• http://www.phoronix.com/scan.php?page=news_item&px=MTEzMTI
• "An empirical analysis of KSM based memory sharing in virtualized systems"
  PDF, 53 sider:
  
  • http://www.cse.iitb.ac.in/synerg/lib/exe/fetch.php?media=public:students:shashankr:mtp_report_final.pdf
  • goo.gl shortlink af overnævnte - hvis forum ikke kan håndtere det oprindelige link: http://goo.gl/NSYxlg

/Lars

[AJenbo]

Svært at følge med alt kinesiske tekst, men det ser ud til at det ville give en rimelig besparelse uden at koste alt for meget CPU, så måske kunne det også være brugbart for computere med meget lidt ram, både ældre eller indlejrede. Hukommelse er dog også noget man efterhånden får smidt i nakken.

[NickyThomassen]

Spændende stuff, tak for delingen

Jeg har dog lidt problemer med at læse den indiske afhandling, uden at læse den med indisk accent...