Memory ballooning nel sistema operativo


13

Alcuni hypervisor ottimizzano l'utilizzo della memoria utilizzando un metodo chiamato ballooning (almeno così lo chiama KVM), questo metodo deduplica la memoria tra macchine virtuali e imposta le pagine comuni in sola lettura con copia in scrittura.
Questo è il contrario di una chiamata fork.

È possibile implementare a livello di sistema operativo per i processi (stavo pensando principalmente alla duplicazione della memoria durante la navigazione con Chromium con più schede sullo stesso sito), è già stata implementata?

Risposte:


14

In realtà, ciò che hai descritto confonde la mongolfiera e la "fusione della stessa pagina". Proverò ad approfondire i due per rendere evidente la distinzione.

Memory ballooning

Questo è un trucco per assicurarsi che parte della memoria allocata alla macchina virtuale guest rimanga utilizzabile da un altro guest o dall'host stesso (cache, ecc.). È fatto nel modo seguente:

Il kernel guest viene iniettato con un driver, che monitora l'utilizzo della memoria guest e "ruba" parte della memoria non utilizzata (allocandola per sé nello spazio di memoria guest, assicurandosi così che nulla su questo guest possa toccare quell'intervallo).

Quindi informa il kernel host, che può effettivamente rimuovere queste pagine di memoria dal core, che non verranno utilizzate nel guest (fino a quando il guest non sperimenta una certa pressione di memoria, a quel punto il fumetto si sgonfia e utilizza questi intervalli di nuovo).

In definitiva, il kernel può allocare esattamente la stessa memoria a un altro guest e rendere l'utilizzo della memoria molto più efficiente se i guest sono in esecuzione con molta memoria libera.

Stessa pagina unita

Questa tecnica identifica pagine di memoria identiche, che per qualche motivo non sono già contrassegnate come "quasi sola lettura" con copia su scrittura e le contrassegna come tali.

Ora, a livello di sistema operativo, esiste una necessità limitata di questo tipo di trucchi. Abbastanza semplicemente, la maggior parte delle volte quando si hanno identiche pagine di memoria, sono già di sola lettura (a volte anche senza CoW), poiché si tratta principalmente di codice di applicazioni, librerie ecc. Vengono aperte in modo nativo tramite una mappa di memoria e quindi il kernel può mantenere solo una copia di essi nel core (se presente, può anche sfogliarlo completamente e consentirne il paging dall'archivio primario in base alle esigenze).

A livello di sistema operativo virtualizzato, lo stesso principio viene applicato correttamente in ciascun sottosistema guest. Tuttavia, il kernel host, non ha idea se due dei guest eseguono principalmente lo stesso codice e quindi condividono la stessa memoria: i guest non comunicano per coordinarlo.

Questo è il motivo per cui occasionalmente può scansionare l'intero sistema alla ricerca di pagine di memoria identiche - il più delle volte, saranno identiche tra i sistemi operativi guest, non all'interno di ciascuno - il kernel guest fa un lavoro decente mantenendo la memoria pulita nel suo intervallo. Pertanto, nel tipico ambiente VM, in cui un kernel host gestisce oltre 50 guest, il risparmio di memoria può essere piuttosto sostanziale.

Entrambi in una volta

L'aerostato e l'unione di pagine uguali possono coesistere molto bene, ottenendo un sovraccarico di memoria piuttosto consistente per sistemi identici.


Per rispondere alla tua domanda: la stessa fusione di pagine può e talvolta è abilitata a livello di sistema operativo. Ha a che fare con la condivisione della pagina che viene interpretata e quindi potrebbe essere identica senza avere lo stesso file di backup.

Nel tuo esempio Chromium - i file binari del processo sono già deduplicati attraverso la mappa di avvio di sola lettura - condividono lo stesso spazio di memoria. Le cache di pagina (contenuto delle schede) sono generalmente condivise anche tra processi (copia-scrittura-scrittura di sola lettura) a causa del modo in cui viene gestita la cache del disco - lo stesso file su disco può essere aperto in modo simultaneo tra processi diversi nella VM senso ottimale.

Il vantaggio sarebbe più evidente con lo stato condiviso di diversi motori Javascript, ma non sono sicuro che siano allocati nello stesso identico layout di memoria, assicurando che l'intera pagina di memoria sia identica.

Questo è diverso sui sistemi mobili. Android, ad esempio, utilizza ampiamente KSM per deduplicare codice identico tra applicazioni diverse.

In entrambi i casi, puoi abilitarlo tu stesso su Linux (Kernel SamePage Merging). L'autista esporta varie statistiche che, dopo aver letto questa risposta, dovresti essere in grado di interpretare e prendere la tua decisione se è una buona corrispondenza per il tuo scopo.

https://www.kernel.org/doc/Documentation/vm/ksm.txt


3
La fusione nella stessa pagina viene anche definita "memoria trascendente", a seconda dell'hypervisor (e dell'età).
Tim Post

Grazie, vedo che KSM richiede che l'applicazione ne sia consapevole e, da una (rapida) ricerca, Chromium non la supporta al momento. Sono consapevole che i binari sono deduplicati, ma mi riferisco principalmente all'output JIT e agli script non elaborati che mettono a dura prova la mia RAM ...

Anche gli script non elaborati in Chromium vengono deduplicati: atterrano nella cache del disco come con tutti gli altri oggetti Web e la cache del disco viene mappata, non letta.
qdot

Gli script non elaborati vengono mappati, ma anche gli script comuni (come jQuery e Angular.js) vengono replicati nella cache e non sono abbinati tra loro poiché si fa un uso pesante di CDN e repliche esatte di file di script sui vari server del sito.

Questo probabilmente dovrebbe finire in chat, ma mi piacerebbe vedere le tue statistiche dal KSM di Linux.
qdot,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.