CRAM stelt een andere manier voor om het geheugen van servers te benutten: het bijhouden van geheugenpagina’s in gecomprimeerde vorm en het mogelijk maken dat de processor rechtstreeks gegevens hiervan leest met behulp van gespecialiseerde hardware, zonder dat Linux elke pagina eerst hoeft te herstellen en decomprimeren voordat deze kan worden gebruikt. Het voorstel, gepresenteerd door Gregory Price van Meta tijdens de Linux Plumbers Conference, probeert enkele beperkingen van huidige softwarematige oplossingen zoals zram en zswap te overwinnen.
De kernpunten van CRAM in 30 seconden
- CRAM introduceert een gecomprimeerd geheugen dat rechtstreeks toegankelijk is voor de processor via een controller voor compressie en decompressie, geïntegreerd in de hardware.
- In tegenstelling tot zram en zswap, is het doel van CRAM te voorkomen dat Linux een pagina eerst moet reconstrueren in het conventionele geheugen voordat deze wordt uitgelezen.
- De voorgestelde aanpak omvat het verplaatsen van pagina’s naar gewoon DDRAM wanneer een schrijfactie ze moet wijzigen.
- Tests toonden een leesprestatiewinst tot 452 keer hoger dan zram in een scenario dat was ontworpen om bepaalde kosten te isoleren.
- Het idee kan helpen om het fysiek geheugen van servers efficiënter te benutten, maar vereist speciale hardware en is nog geen algemeen beschikbare commerciële oplossing.
De belangstelling voor CRAM neemt toe op een moment dat de kosten van geheugen voor datacenters een zorgenkind zijn. Als een server meer data kan opslaan in dezelfde hoeveelheid RAM zonder de leeskosten te verhogen, zou dat de drang kunnen verminderen om meer geheugen aan te schaffen. De waarde van het voorstel hangt echter af van de prestaties onder echte workloads en van fabrikanten die de juiste hardware ontwikkelen.
Waarom lossen zram en zswap niet hetzelfde probleem op?
Linux beschikt al over mechanismen om het fysiek benodigde geheugen te verminderen. Twee bekende voorbeelden zijn zram en zswap, hoewel ze niet precies hetzelfde doen.
zram creëert een RAM-backed block-device dat data comprimeert opslaat. Het wordt vaak gebruikt als swapruimte. Wanneer het systeem een pagina daaruit moet terughalen, moet de inhoud worden gereconstrueerd zodat de toepassing deze kan gebruiken.
zswap fungeert als een gecachte, gecomprimeerde buffer vóór een echte swap-apparaat. Het houdt tijdelijk gecomprimeerde pagina’s in geheugen vast en kan het aantal lees- en schrijfbewerkingen naar secundair opslag verminderen. Als de cache ruimte moet vrijmaken, kunnen de gegevens uiteindelijk naar de swap worden geschreven.
Beide mechanismen verbeteren het geheugengebruik, maar blijven afhankelijk van het besturingssysteem om data weer te herstellen. Wanneer een applicatie toegang wil tot een pagina die niet in actief geheugen ligt, moet Linux een paginafault afhandelen, de gegevens herstellen en deze descomprimeren via software.
Dat proces brengt extra werk met zich mee voordat de applicatie verder kan. De kosten hangen af van de compressie-algoritmen, de werkbelasting en waar de gegevens zich bevinden.
CRAM probeert dat punt te doorbreken. Het voorstel is niet slechts om meer pagina’s te comprimeren, maar om de processor rechtstreeks gegevens uit gecomprimeerd geheugen te laten lezen zonder dat Linux eerst alles in het conventionele RAM hoeft te reconstrueren.
CRAM vereist hardware die gegevens direct kan lezen uit gecomprimeerd geheugen
Het ontwerp plaatst compressie- en decompressiefuncties in een hardwarecontroller die is gekoppeld aan het geheugen. Pagina’s blijven gecomprimeerd binnen het apparaat en de controller levert de gedecomprimeerde gegevens zodra de processor een leeshard vraagt.
Voor applicaties blijft de toegang via gewone geheugenadressen intact. De complexiteit ligt vooral in de infrastructuur die het gecomprimeerde geheugen beheert en de dataoverdrachten regelt.
Dit is belangrijk omdat compressie niet meer door het besturingssysteem zelf wordt gedaan vóór elke pagina-herstel. Vooral bij workloads waar gegevens frequent worden gelezen en weinig worden gewijzigd, kan deze aanpak de overhead van geheugenherstel verminderen.
Toch vermindert de aanpak niet de kernel-werking volledig. Linux blijft de locatie van pagina’s moeten beheren, hun bescherming, het vrijmaken van geheugen, migraties en beslissingen over welke data gecomprimeerd blijven en welke weer naar gewoon geheugen gaan.
Er is ook een fysieke beperking: niet alle gecomprimeerde data nemen minder ruimte in beslag. Een pagina van 4 KiB kan verkleinen tot ongeveer 1 KiB bij goede compressie, maar data die nauwelijks te comprimeren zijn, blijven ongeveer hetzelfde formaat houden.
Schrijven brengt een extra uitdaging met zich mee. Als een gecomprimeerde pagina 1 KiB gebruikt en een wijziging zorgt ervoor dat er 4 KiB nodig zijn, moet het apparaat hiermee omgaan. De aanpak is dat gecomprimeerde pagina’s in ‘read-only’ modus blijven en dat een wijziging de pagina eerst naar gewoon RAM verplaatst vóór de modificatie.
Deze werkwijze is vooral nuttig bij leesintensieve workloads, maar hangt af van de verhouding tussen lezen en schrijven, de compressibiliteit van gegevens en hoe vaak migraties nodig zijn.
De prestatieverbetering van 452 keer moet in context worden gezien
Een opvallende uitschieter bij CRAM is een prestatieverbetering tot wel 452 keer bij lezen vergeleken met zram. Het is echter belangrijk te begrijpen dat deze cijfers niet automatisch betekenen dat volledige applicaties 452 keer sneller draaien.
De tests werden uitgevoerd in een omgeving met DRAM die het gedrag van een toekomstig gecomprimeerd geheugenapparaat simuleerde. Het doel was om de overhead van pagina-fouten en software decompressie te isoleren en de mogelijke voordelen van direct lezen uit gecomprimeerd geheugen te evalueren.
Dat is een belangrijke nuance. Een prestatiecijfer uit een specifieke test zegt niet direct iets over de algehele prestatie van een server, database of applicatie. Om dat te bepalen, zijn echte hardware-onderdelen nodig, met verschillende werkbelastingen en metingen die zowel lezen als schrijven in rekening brengen, inclusief het geheugengebruik.
Ook vereist de aanpak hardware die gecomprimeerd geheugen direct kan beschikbaar stellen. Technologieën zoals Compute Express Link (CXL), die communicatie tussen processors en geheugen- of acceleratordevices mogelijk maken, kunnen een rode draad vormen voor het ontwerpen van dergelijke systemen. Dit betekent niet dat alle CXL-apparaten al ondersteuning bieden voor CRAM of dat deze technologie al algemeen beschikbaar is.
De schaarste en hoge kosten van RAM kunnen de belangstelling voor deze benadering vergroten. In datacenters kan een efficiënter gebruik van geheugen de noodzaak verminderen om fysieke capaciteit uit te breiden. Maar de potentiële besparing moet opwegen tegen de hardwarekosten, complexiteit van integratie en de verschillende workload-specifieke beperkingen.
Voorlopig moet CRAM worden gezien als een architectuurvoorstel dat de mogelijkheden van direct gebruik van gecomprimeerd geheugen onderzoekt. Tests in DRAM helpen het concept te beoordelen, maar het moet nog worden aangetoond hoe het zich houdt met hardware die dit daadwerkelijk ondersteunt.
Veelgestelde vragen
Wat is CRAM in Linux?
CRAM is een voorstel voor een gecomprimeerd geheugen dat rechtstreeks toegankelijk is via gespecialiseerde hardware. Het doel is dat de processor gegevens uit gecomprimeerde geheugenpagina’s kan lezen zonder dat Linux eerst elke pagina in het conventionele geheugen hoeft te herstellen en decomprimeren.
Hoe verschilt CRAM van zram en zswap?
zram biedt een RAM-backed block-apparaat dat data comprimeert opslaat en wordt meestal gebruikt als swapruimte. zswap houdt een gecachte, gecomprimeerde buffer voor bewegende data vóór een echt swap-apparaat. CRAM maakt rechtstreeks hardwarematig toegang mogelijk tot gecomprimeerde gegevens, met een ander werkmodel.
Maakt CRAM applicaties 452 keer sneller?
Nee. Die cijfers tonen een prestatieverbetering bij lezen in een specifieke test die ontworpen is om overhead van pagina-fouten en decompressie te isoleren. Ze betekenen niet dat alle applicaties of servers automatisch die snelheidstoename krijgen.
Kan ik CRAM nu in elk server gebruiken?
Nee. Het vereist hardware die geheugen gecomprimeerd en direct toegankelijk maakt. De tests met DRAM zijn bedoeld om het concept te evalueren, maar er is nog geen brede commerciële hardware beschikbaar die CRAM ondersteunt.