Mobil Cihazlarda ZRAM ve Swap Bellek Yönetimi: Düşük Bellek Katili (LMK) Algoritması: Uzun vadeli riskler ve telafisi zor hatalar

Bölüm 1: Bu Nedir ve Neden Hayati Önem Taşır?

Bu çalışma, mobil işletim sistemlerinde (özellikle Android/Linux çekirdeği tabanlı ekosistemlerde) fiziksel RAM kısıtlamalarını aşmak amacıyla kullanılan sıkıştırılmış blok cihazı ZRAM, dinamik swap alanları ve bellek baskısı altındaki süreç sonlandırma mekanizması olan Düşük Bellek Katili (LMKD) üçgeninin sistematik analizini kapsar. Doğal döngü açısından; bellek hiyerarşisinde “soğuk” sayfaların sıkıştırılarak RAM içinde tutulması (ZRAM), “dondurulmuş” süreçlerin disk tabanlı swap’a itilmesi ve OOM (Out of Memory) skorlama algoritması üzerinden gerçekleştirilen agresif süreç katli arasındaki etkileşimi modeller. Metodolojik yaklaşım; çekirdek seviyesinde mm/vmscan.c ve drivers/block/zram alt sistemlerinin davranışsal analizi, oom_score_adj parametrelerinin kullanıcı alanı démonu (lmkd) tarafından nasıl tüketildiği ve bu döngünün gecikme (latency), pil ömrü (write amplification) ve UX (kullanıcı deneyimi) üzerindeki ikinci dereceden etkilerinin nicel/kisel değerlendirmesini içerir. Temel parametreler; swappiness, watermark_scale_factor, zram_fraction ve LMK minfree seviyeleridir.

Bölüm 2: Perde Arkası: Sistem Nasıl Çalışıyor?

Mekanizma, sanal bellek yöneticisinin (VMS) sayfa hatası (page fault) işleme sürecinde devreye girer. Fiziksel sayfa çerçeveleri (page frames) tükendiğinde kswapd veya doğrudan geri kazanım (direct reclaim) yolları tetiklenir. ZRAM, blok katmanında bir sıkıştırma motoru (LZ4, ZSTD, LZO-RLE) kullanarak anonim sayfaları (anon pages) RAM içinde sıkıştırılmış bloklara dönüştürür; bu, disk I/O’sunu (UFS/eMMC yazma gecikmesi) RAM erişim gecikmesi + CPU sıkıştırma maliyeti ile değiştirir. Swap alanı (genellikle zram0 blok cihazı üzerine mkswap/swapon ile oluşturulur) öncelikli olarak ZRAM’a atanır; düşük öncelikli disk swap (varsa) yedek olarak kalır. LMKD ise kullanıcı alanında çalışan bir démon olup, çekirdekten oom_score ve vmpressure sinyallerini dinler. Bellek baskısı minfree eşiklerinin altına düştüğünde, oom_score_adj değeri en yüksek olan (genellikle arka planda bekleyen, büyük heap’e sahip) süreçlere SIGKILL gönderir. Bu “katil” davranışı, çekirdeğin kendi OOM Killer’ından (oom_kill_process) farklı olarak politika tabanlı, ayarlanabilir ve proaktiftir.

Bölüm 3: Bilim Dünyası ve Uzmanlar Nasıl İnceliyor?

Analiz, Linux Çekirdeği Bellek Yönetimi (MM) alt sisteminin kod tabanı (v6.x serisi) ve Android Ortak Çekirdeği (ACK) yamaları üzerinden yapılır. Standart referanslar; Documentation/admin-guide/mm/zram.rst, Documentation/block/zram.txt ve Android CDD (Compatibility Definition Document) Bölüm 7 (Bellek ve Depolama) gereklilikleridir. Ölçüm metodolojisi; ftrace/perf ile mm_vmscan_* olaylarının izlenmesi, zramctl ve /sys/block/zram0/stat arayüzleri üzerinden sıkıştırma oranı (compr_data_size / orig_data_size), yazma amplifikasyonu (write amplification factor) ve direct_reclaim gecikmesi ölçümlerini içerir. LMK davranışı için lmkd kaynak kodundaki LowMemoryKiller sınıfı ve oom_score_adj hesaplama mantığı (adj slotları: 0, 100, 200… 900, 1000) incelenir. Protokol olarak; AOSP vmstat/meminfo dökümleri, bugreport analizleri ve CTS (Compatibility Test Suite) CtsMemoryTestCases senaryoları referans alınır. Enerji verimliliği için power_profile.xml içindeki memory.controller maliyet tabloları kullanılır.

Bölüm 4: Önemli Parametreler ve Karşılaştırma Rehberi

Bölüm 5: Günlük Hayatta ve Doğada Nerede Karşımıza Çıkar?

Gerçek dünya senaryolarında; 4GB/6GB RAM’li orta segment cihazlarda, agresif çoklu görev (multitasking) sırasında ZRAM olmadan LMK, arka plandaki müzik uygulaması veya harita navigasyonunu katlederek kullanıcı deneyimini kırar. ZRAM etkinleştirildiğinde (örn. 2GB ZRAM, ZSTD), aynı senaryoda sıkıştırılan sayfalar RAM’de kaldığı için direct_reclaim gecikmesi 120ms’den 15ms’ye düşer ve LMK tetiklenmez. Yüksek segmentte (12GB+ RAM), zram_writeback etkinleştirilerek “soğuk” sayfalar (örn. 3 gün önce açılmış bir oyun asset’i) UFS’ye yazılır, ZRAM alanı “sıcak” veriler için boşaltılır. Kritik vaka analizi: Bir e-ticarete uygulamasında WebView render süreci aniden 800MB heap tüketirse, LMK oom_score_adj=900 slotundaki süreci öldürürken, ZRAM bu sürecin anonim sayfalarını sıkıştırarak ömrünü uzatabilir; ancak WebView içindeki V8 motorunun GC (Garbage Collector) döngüleri sıkıştırılmış sayfalara erişimde major fault üreterek CPU’yu %100’e çıkarır (CPU thrashing). Bu durum, ZRAM boyutunun RAM’in %50’sini geçmemesi gerektiğini kanıtlar.

Bölüm 6: Karşılaşılan Zorluklar ve Pratik Çözümler

Birincil operasyonel darboğaz CPU Thrashing‘dir: Bellek baskısı yüksekken ZRAM sürekli sıkıştırma/açma (compress/decompress) döngüsüne girer, CPU çekirdekleri kworker/uXX:zram işlemleriyle meşgul olur, UI iş parçacığı (RenderThread/MainThread) zaman dilimi (time slice) alamaz. İkinci risk Yazma Amplifikasyonu (Write Amplification – WA)‘dur: zram_writeback etkinse, sıkıştırılmış sayfalar UFS’e yazılır; sık sık silinen/yeniden yazılan sayfalar flash hücrelerinin ömrünü tüketir (TBW – Terabytes Written). Üçüncü risk LMK “False Positive” Katliamıdır: minfree eşikleri yanlış kalibre edilirse (örn. OnePlus/ColorOS eski sürümlerinde), ön plandaki uygulama bile oom_score_adj hesaplama hatası nedeniyle öldürülebilir. Çözüm stratejileri: 1) Uyarlamalı Swappiness: vmpressure seviyesine göre swappiness dinamik ayarlama (Android 13+ AppStandbyBucket entegrasyonu). 2) HW Sıkıştırma: ARMv8.2-A CRC32/SHA uzantıları veya özel DSP/IP blokları (Google Tensor G3 BigWave, Qualcomm QCOM_ZRAM) ile CPU yükünü offlaod etme. 3) Sayfa Yaşam Döngüsü Takibi: idle_page_tracking ile erişilmeyen sayfaları proaktif sıkıştırma/disk yazma. 4) LMK Politika Ayarlama: minfree değerlerini cihaz RAM boyutuna göre logaritmik ölçeklendirme (Doğrusal değil).

Bölüm 7: Gelecek Perspektifi ve Yeni Gelişmeler

Son gelişmelerde; Linux 6.6+ ile gelen ZRAM Multi-Stream Desteği (max_comp_streams varsayılan CPU sayısına eşitlendi), kilitleme (lock contention) darboğazını kırdı. ZSTD 1.5.5+ hızlı seviyelerde (level 1-3) LZ4’ü hızda geçerken oranda %15-20 üstünlük sağlıyor. Android 14 (U) ve 15 (V)’de lmkd yerine memfd tabanlı anonim dosya eşlemeleri ve MADV_COLD/MADV_PAGEOUT ipuçları ile kullanıcı alanı müdahalesi artırıldı. Kernel Samepage Merging (KSM) mobilde güvenlik riski (side-channel) nedeniyle devre dışı bırakılsa da, UKSM (Ultra KSM) veya KSM+ZRAM hibrit modelleri sunucu taraflı bulut oyun (cloud gaming) istemcileri için test ediliyor. Gelecek 5-10 yıl projeksiyonu: CXL (Compute Express Link) tabanlı genişletilmiş bellek mobil SoC’lerde (LPDDR5X/6) fiziksel swap katmanı olarak gelecek; ZRAM o zaman “L1 Swap Cache” konumuna, CXL-attached memory “L2 Swap” konumuna oturacak. Makine Öğrenmesi Tabanlı Tahmini Bellek Yönetimi (ML-based Prefetch/Reclaim), oom_score hesaplamasını statik kurallardan dinamik tahmine (LSTM/Transformer modelleri ile sonraki 5 saniyelik bellek basıncı tahmini) taşıyacak.

Bölüm 8: Merak Edilen Sorular ve Cevaplar

Soru 1: ZRAM fiziki RAM mi artırır?

Cevap: Hayır. ZRAM, mevcut fiziksel RAM’in bir kısmını ayırarak (örneğin 4GB RAM’de 1GB ZRAM havuzu), o alana yazılan verileri sıkıştırarak etkin kapasiteyi artırır. 1GB ZRAM, 3x sıkıştırma oranında ~3GB anonim veriyi tutabilir. Bu, “sanal” bir RAM artışıdır; fiziksel DRAM hücre sayısını değiştirmez.

Soru 2: LMK ve Çekirdek OOM Killer (OOM Killer) arasındaki fark nedir?

Cevap: Çekirdek OOM Killer (oom_kill_process), bellek tamamen bittiğinde (GFP_ATOMIC bile sağlanamazsa) son çare olarak rastgele (veya oom_score bazlı) bir süreci öldürür. LMKD (Low Memory Killer Daemon) ise kullanıcı alanında çalışan, Android’e özgü bir démon olup, bellek bitmeden önce (proaktif), minfree eşiklerine göre politika tabanlı (arka plan uygulamalarını hedef alarak) SIGKILL gönderir. LMK, OOM Killer’ın devreye girmemesini amaçlar.

Soru 3: swappiness=100 mobil cihazlarda her zaman en iyisi midir?

Cevap: Değil. swappiness=100, anonim sayfa geri kazanımını dosya sayfası (page cache) geri kazanımıyla eşit derecede agresif hale getirir. Düşük RAM’li cihazlarda (≤4GB) faydalıdır; ancak yüksek RAM’li (12GB+) cihazlarda gereksiz CPU döngüleri ve pil tüketimine yol açabilir. Modern Android’lerde swappiness statik değil, vmpressure seviyesine göre dinamik ayarlanır.

Soru 4: ZRAM için hangi sıkıştırma algoritması seçilmeli? LZ4 mü ZSTD mi?

Cevap: LZ4: En düşük gecikme, en yüksek throughput, donanım hızlandırıcı olmadan bile güvenli. ZSTD: Daha yüksek sıkıştırma oranı (daha fazla etkin RAM), ancak daha yüksek CPU maliyeti. Modern SoC’lerde (Snapdragon 8 Gen 2/3, Tensor G3) ZSTD donanım hızlandırıcısı varsa ZSTD (level 1-3) tercih edilir; yoksa LZ4 daha güvenlidir.

Soru 5: zram_writeback etkinleştirilirse pil ömrü nasıl etkilenir?

Cevap: Olumsuz etkilenir. Sıkıştırılmış sayfaların UFS/eMMC’ye yazılması (writeback), flash bellekte Yazma Amplifikasyonu (WA) yaratır. Bu, pil tüketimini artırır (CPU + Flash kontrolcüsü aktivitesi) ve depolama ömrünü (TBW) kısaltır. Sadece RAM baskısı sürekli yüksekse (örn. 6GB RAM cihazda 8GB aktif veri) faydalıdır; aksi takdirde kapalı tutulmalıdır.

Soru 6: Geliştirici olarak uygulamamın LMK tarafından öldürülmesini nasıl engelleyebilirim?

Cevap: 1) onTrimMemory(TRIM_MEMORY_UI_HIDDEN) callback’inde büyük önbellekleri (Bitmap, WebView cache, JSON response) serbest bırakın. 2) ActivityManager.getMyMemoryState(RunningAppProcessInfo) ile kendi oom_score_adj skorunuzu izleyin. 3) Process.setProcessMemoryState (System API, root/privileged gerektirir) veya ActivityManager.setProcessMemoryTrimLevel kullanarak süreç durumunu “Ön Plan Servisi” (Foreground Service) veya “Görünür” (Visible) seviyesine çekin. 4) Bellek sızıntılarını (LeakCanary) ve büyük heap ayırmaları (Large Object Allocation) profil edin.

Bölüm 9: Bilmeniz Gereken Temel Terimler

Anonim Sayfa (Anonymous Page): Dosya sistemine (disk) bağlı olmayan, sadece sanal bellek alanında yaşayan ve swap alanına yazılabilecek sayfalar (Heap, Stack, mmap(MAP_ANONYMOUS)). ZRAM’in hedef kitlesidir.

Sayfa Hatasi (Page Fault): CPU’nin sanal adrese erişmeye çalıştığında, karşılık gelen fiziksel sayfa RAM’de yoksa (swap’ta veya dosyada) veya sayfa tablosu girişi geçersizse tetiklenen istisna (exception). Major Fault disk I/O gerektirir, Minor Fault sadece sayfa tablosu güncellemesi gerektirir.

Doğrudan Geri Kazanım (Direct Reclaim): Bir süreç bellek ayırma isteğinde bulunduğunda (örn. kmalloc, page_alloc), yeterli serbest sayfa yoksa o anki iş parçacığı tarafından senkron olarak gerçekleştirilen sayfa temizleme/swap-out işlemidir. UI donmalarının (jank) ana nedenidir.

Watermark (Su Seviyesi / Eşik Değeri): Çekirdeğin bellek durumunu sınıflandırması için kullanılan min, low, high seviyeleri. minfree LMK için, watermark çekirdek kswapd için tetikleme noktalarıdır.

Yazma Amplifikasyonu (Write Amplification – WA): Flash bellekte (UFS/eMMC/SSD), mantıksal veri yazılma miktarının fiziksel hücre yazılma miktarına oranı. ZRAM writeback ve sık sık sıkıştırma döngüleri WA’yı artırır.

OOM Score Adj (OOM Puanı Ayarlaması): Sürecin Ön Bellek Katili (OOM Killer/LMK) tarafından seçilme olasılığını belirleyen kullanıcı alanı parametresi (-1000 ile +1000 arası). Negatif değer koruma, pozitif değer hedef anlamına gelir.

Bölüm 10: Özet ve Çıkarılması Gereken Dersler

ZRAM ve LMK, mobil cihazlarda fiziksel RAM kısıtlamasını maskeleyen “yazılımsal sanallaştırma” katmanıdır; ancak bu maskeleme maliyetsiz değildir. Analizler, ZRAM’in (LZ4/ZSTD) doğru boyutlandırıldığında (RAM’in %25-33’ü) ve swappiness/watermark parametreleri iş yükü profiline göre kalibre edildiğinde, direct_reclaim gecikmesini %80-90 azaltarak LMK tetikleme sıklığını drastik şekilde düşürdüğünü gösterir. Ancak, kontrolsüz büyüme (unbounded growth), CPU thrashing ve flash yazma amplifikasyonu (WA) riskleri, “daha fazla ZRAM her zaman iyidir” mitosunu yıkar. Stratejik yol haritası şudur: 1) Statik ayarları terk edin; Android 14+ AppStandbyBucket ve vmpressure sinyalleriyle dinamik swappiness/zram_size yönetimine geçin. 2) Donanım hızlandırıcılarını (HW Accel) zorunlu kılın; yazılım tabanlı ZSTD, yüksek yükde CPU’yu kilitler. 3) LMK politikasını “Ölüm”den “Dondurma”ya (SIGSTOP/CRIU) evrilirin; kullanıcı verisi kaybını (oyun durumu, form verisi) önlemek için süreç öldürme yerine kontrol noktası (checkpoint) alma mimarilerine (Android 15+ ProcessFreezer deneyleri) yatırım yapın. 4) Gelecek için CXL/Disaggregated Memory altyapısını mobil SoC tasarımına entegre edin; ZRAM o zaman “L1 Swap Cache” olacak, fiziksel swap CXL katmanına kayacak. Karar vericiler için özetle: ZRAM/LMK bir “yama” değil, “bellek hiyerarşisinin ayrılmaz bir parçası”dır ve bu parça, donanım/yazılım ortak tasarımı (Hardware/Software Co-design) ile yönetilmelidir.