Mobil Cihazlarda ZRAM ve Swap Bellek Yönetimi: Düşük Bellek Katili (LMK) Algoritması

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

Mobil cihazlarda fiziksel DRAM kısıtlamaları, çoklu görev (multitasking) performansını ve uygulama yaşam döngüsü yönetimini belirleyen kritik kısıtlardır. Bu çalışma; Linux çekirdeğinin sanal bellek alt sisteminin mobil uyarlaması olan ZRAM (Sıkıştırılmış RAM Blok Cihazı), Swap mekanizmaları ve Android’in kullanıcı alanında (userspace) çalışan Düşük Bellek Katili (LMKD – Low Memory Killer Daemon) algoritmasının üçgen etkileşimini inceler. Doğal döngü açısından; bellek basıncı (memory pressure) sinyallerinin (PSI – Pressure Stall Information), sayfa geri kazanma (page reclaim) stratejileri ve OOM (Out-Of-Memory) skorlama modelleri üzerinden kurulur. Metodolojik yaklaşım; çekirdek seviyesinde mm/vmscan.c ve drivers/block/zram/ yollarındaki kaynak kod analizi, AOSP (Android Open Source Project) lmkd kaynakları ve Google’ın “Memory Management” resmi kılavuzları ile IEEE/ACM literatüründeki akademik konsensüsün (örn. “Zswap vs ZRAM” karşılaştırmalı çalışmaları) sentezini kapsar. Temel parametreler; swappiness, watermark_scale_factor, zram_fraction ve oom_score_adj seviyeleridir.

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

Mekanizma, bellek hiyerarşisinde “aktif” ve “pasif” sayfa listelerinin (LRU – Least Recently Used) yönetimi üzerine kuruludur. ZRAM, fiziksel RAM’in bir kısmını (örn. %25-50) LZ4/ZSTD algoritmalarıyla sıkıştırılmış blok cihazına (/dev/zram0) dönüştürür; bu sayede swap yazma/okuma işlemleri flash depolama (UFS/eMMC) yerine CPU-bound sıkıştırma/yayma işlemlerine indirgenir, gecikme mikrosaniyeye düşer. Swap alanı, anonim sayfaların (anon pages) fiziksel çerçeve boşaltılması için hedef alan olur. LMKD, çekirdekten gelen PSI (Pressure Stall Information) metriklerini (/proc/pressure/memory) dinler; “some” ve “full” stall yüzdeleri eşik değerleri aştığında, oom_score_adj değerlerine göre (arka plan uygulamaları > önceki plan servisleri > sistem süreçleri) süreçleri SIGKILL ile sonlandırır. Sebep-sonuç zinciri: Bellek basıncı -> Sayfa geri kazanma (kswapd/direct reclaim) yetersiz kalır -> PSI tetiklenir -> LMKD müdahale eder -> Süreç öldürülür -> Bellek boşalır.

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

Endüstriyel normlar; Linux Kernel Documentation (admin-guide/mm/zram.rst, blockdev/zram.txt), Android CDD (Compatibility Definition Document) Section 7.6.1 (Bellek Gereksinimleri) ve AOSP lmkd README standartlarını referans alır. Ölçüm metodolojisi; perf stat, ftrace (tracepoints: mm_vmscan_*, vmscan_wakeup_kswapd), vmstat sayaçları (pgscan_kswapd, pgsteal_direct, pswpout, pswpin) ve ZRAM istatistikleri (/sys/block/zram0/stat: compr_data_size, orig_data_size, mem_used_total) üzerinden yapılır. Akademik konsensüs; USENIX ATC ve ASPLOS konferanslarında sunulan “Compressed Caching” (IBM Research, 2000) ve modern “ZRAM: The Good, The Bad, The Ugly” (Linux Plumbers Conf) çalışmalarıyla şekillenir. Protokoller; zramctl (userspace yönetim), sysfs arayüzü parametreleme (disksize, comp_algorithm, writeback) ve lmkd yapılandırma dosyası (/vendor/etc/lmkd.xml veya /system/etc/lmkd.xml) üzerindeki minfree/oom_score_adj eşleme tabloları ile uygulanı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?

Flagship cihazlarda (12GB+ RAM) ZRAM boyutu 4-6GB, zstd algoritmasıyla yapılandırılır; bu sayede 20+ ağır uygulama (kamera, oyun, harita) aynı anda canlı tutulur. Orta segment (4-6GB RAM) cihazlarda ise lz4 tercih edilerek CPU yükü minimize edilir ve writeback aktif edilerek flash’a taşma sağlanır. Kritik Vaka Analizi: “App Launch Latency” testlerinde (Google launchbench), ZRAM olmadan 4GB cihazda cold start 1.8s; ZRAM (zstd, %50 RAM) ile 1.1s’ye düşer. Oyun Senaryosu: GameMode API’si etkin olduğunda LMKD oom_score_adj değerlerini geçici olarak yükseltir (system server koruma), kswapd watermark_boost_factor ile proaktif hale getirilir; bu da frame time jitter’ını (90. percentil) %40 azaltır. Go Edition (Düşük Bellek): 2GB RAM cihazlarda zram_fraction=4 (RAM’in %25’i), swappiness=100, agresif minfree değerleri ile sistem kararlılığı sağlanır; kullanıcı deneyimi “uygulama yeniden başlatma” maliyeti ile dengelenir.

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

Operasyonel Darboğaz 1: CPU-Sıkıştırma Maliyeti. Yoğun bellek basıncında kworker/uXX:zram thread’leri CPU çekirdeklerini tüketir (CPU contention). Çözüm: comp_algorithm=zstd (hw acceleration: crypto-simd/arm64-ce) kullanımı ve max_comp_streams = CPU çekirdek sayısı ayarı. Risk 2: Yazma Geri Yüklemesi (Writeback) ve Flash Ömrü. zram_writeback etkinse soğuk sayfalar UFS’e yazılır; Write Amplification Factor (WAF) artar. Çözüm: writeback_limit_mb (günlük/kotali kota) ve idle/huge yazma stratejileri ile flash ömrü korunur. Hata Modu 3: LMKD – Kswapd Yarışı (Race Condition). LMKD süreç öldürürken kswapd hâlâ sayfa yazıyorsa SIGKILL sonrası sayfa tabloları temizlenirken direct reclaim gecikmesi oluşur. Çözüm: Android 12+ lmkd “kill timeout” ve oom_reaper thread’i ile senkronizasyon. Zorluk 4: Parçalanma (Fragmentation). ZRAM havuzu dolduğunda compaction başarısız olursa high-order allocationlar (GPU bufferlar) başarısız olur. Çözüm: page-cluster=0 ve proaktif compact_unevictable_allowed=1 ayarları.

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

Linux 6.6+ / Android 14 (UpsideDownCake) Yenilikleri: Multi-Gen LRU (Multi-Generational LRU) varsayılan hale getirildi; anon ve file LRU listeleri “gen” (nesil) bazlı yönetilerek kswapd verimliliği %30+ arttırıldı. ZRAM Writeback Improvements: writeback artık blk-cgroup (io.latency) ile entegre, öncelikli I/O trafiği (kullanıcı etkileşimi) engellenmez. LMKD Modernizasyonu: lmkd artık binder transaction tracking ile “önemli” arka plan servislerini (örn. navigasyon, müzik) oom_score_adj dinamik düşürerek koruyor. Gelecek 5-10 Yıllık Projeksiyon: CXL (Compute Express Link) / UFS 4.0+ Zoned Namespaces (ZNS) ile “Computational Storage” yaklaşımları; sıkıştırma işlemleri SSD kontrolcüye offload edilecek (Hardware ZRAM). Persistent Memory (PMEM) entegrasyonu ile anonim sayfalar byte-addressable non-volatile belleğe doğrudan mmap edilecek, swap kavramı “tiered memory management”e evrilecek. ML Tabanlı Tahminci LMK: On-device ML modelleri (TensorFlow Lite Micro) ile uygulama kullanım olasılıkları tahmin edilerek oom_score_adj proaktif ayarlanacak.

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

Soru 1: ZRAM swap alanı mı, RAM alanı mıdır? Performans etkisi nedir?

Cevap: ZRAM, RAM’in içine ayrılmış bir blok cihazıdır (RAM-backed block device). Fiziksel swap alanı (disk) değildir. Veri RAM içinde sıkıştırılarak tutulur. Performans etkisi; disk I/O gecikmesi (ms) yerine CPU sıkıştırma gecikmesi (µs) getirilmesidir. CPU maliyeti (LZ4 ~3-5 GB/s/core) modern mobil SoC’lerde (Cortex-X/A7xx) göz ardı edilebilir düzeydeyken, UFS 3.1/4.0 yazma gecikmesinden (ve flash ömründen) kurtarır.

Soru 2: swappiness=0 yapmak cihazı hızlandırır mı?

Cevap: Hayır, mobilde yanlıştır. swappiness=0 çekirdeği “swap yapmaktan kaçın” der, bu da kswapd‘yi pasifleştirir. Bellek basıncı arttığında direct reclaim (senkron, işlemi bloke eden) tetiklenir; bu da UI donmalarına (jank) yol açar. Mobilde swappiness=60-100 (proaktif swap) ve düşük watermark_scale_factor ile kswapd‘nin arka planda temizleme yapması tercih edilir.

Soru 3: LMKD neden oom_score_adj kullanır, çekirdek OOM Killer (oom_killer) neden yetmez?

Cevap: Çekirdek OOM Killer son çaredir (Panic öncesi), kural tabanlıdır ve kullanıcı deneyimini (UX) bilmez (örn. launcher’ı öldürür). LMKD Userspace‘de çalışır, Android yaşam döngüsü durumunu (ActivityManagerService’den oom_adj alır), PSI metriklerini ve binder iş yükünü bilir. Bu sayede “Görünmeyen arka plan uygulaması” (cached) yerine “Müzik çalar servisi”yi koruyarak akıllı karar verir.

Soru 4: ZRAM boyutu fiziksel RAM’in yarısından fazlası olabilir mi?

Cevap: Teknik olarak disksize RAM’in %100’ü kadar ayarlanabilir (sıkıştırma oranı 2x-3x varsayımıyla). Ancak max_pool_percent (varsayılan %100) ve mem_limit kontrolleri vardır. Pratikte %50-75 (4-6GB RAM’de 2-4GB ZRAM) optimumdur. Çok büyük ZRAM, sıkıştırılamayan veriler (incompressible) için mem_used_total = disksize olma riski yaratır, bu da OOM’a iter.

Soru 5: zram_writeback flash belleği (UFS/eMMC) yakar mı?

Cevap: Evet, Write Amplification (WA) yaratır. Ancak modern UFS 3.1/4.0 kontrolcüleri (SLC cache, wear leveling) ve Android’in writeback_limit_mb (günlük yazma kotası) ile idle yazma stratejisi bu riski yönetir. Kazandığı RAM boşluğu (büyük oyun/uygulama canlı tutma) flash ömründen daha değerlidir. Kritik veri bütünlüğü için zram_writeback opsiyoneldir, zram çekirdeği veri kaybı riski taşımaz (sadece RAM’dedir).

Soru 6: Multi-Gen LRU (Android 14+) eski active/inactive LRU’dan ne farkı var?

Cevap: Eski LRU; sayfaları sadece “aktif/pasif” ikili listeye atar, “yeni ayrılan ama hemen erişilmeyen” sayfaları (thrashing) aktif listede tutar. Multi-Gen LRU; sayfaları erişim zamanına göre Nesil (Generation) 0, 1, 2, 3… olarak sınıflandırır. kswapd en eski nesilden (Gen 3+) taramaya başlar. Bu, “working set” tespitini çok daha hassas yapar, pgscan sayısını azaltır ve direct reclaim ihtiyacını minimize eder.

Bölüm 9: Bilmeniz Gereken Temel Terimler

PSI (Pressure Stall Information): Linux çekirdeği (4.20+) tarafından sunulan, kaynak kısıtlama (CPU, Memory, I/O) derecesini “some” (bazı görevler bekliyor) ve “full” (tüm görevler bekliyor) yüzdeleriyle ölçen metrik arayüzü. LMKD’nin tetikleyici sinyalidir.

LRU (Least Recently Used) / Multi-Gen LRU: Sayfa çerçevelerinin (page frames) erişim sırasına göre tutulduğu liste yapısı. Multi-Gen LRU, sayfaları zaman pencerelerine (nesillere) ayırarak geri kazanma (reclaim) verimliliğini artıran modern algoritmadır.

Anonymous Pages (Anonim Sayfalar): Dosya sistemine (disk) bağlı olmayan, sadece sanal bellekte var olan ve swap/ZRAM’e yazılması gereken sayfalar (Heap, Stack, mmap(MAP_ANONYMOUS), JIT kod önbellekleri).

Direct Reclaim vs Kswapd Reclaim: Direct Reclaim: Bellek isteyen süreç (allocation context) kendi sayfalarını temizlemek için bloklanır (Yüksek gecikme). Kswapd Reclaim: Arka plan daemonu (kswapd) su seviyeleri (watermarks) aşıldığında proaktif temizler (Düşük gecikme).

OOM Score Adj (oom_score_adj): Sürecin OOM katliamında öldürülme olasılığını belirleyen kullanıcı alanı ayarlanabilir puan (-1000 koruma, 0 normal, +1000 ilk öldürülecek). Android bileşen türüne (Foreground, Service, Cached) göre dinamik atanır.

Writeback (ZRAM Writeback): ZRAM havuzundaki “soğuk” (uzun süredir erişilmeyen) sıkıştırılmış sayfaların, RAM basıncını azaltmak için fiziksel depolama (UFS) üzerine yazdırılma işlemi.

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

Mobil bellek yönetimi artık “swap yok” ideolojisinden, ZRAM tabanlı sıkıştırılmış önbellek + PSI güdümlü proaktif geri kazanma + Uygulama yaşam döngüsü farkında LMKD üçgenine evrilmiştir. Akademik konsensüs ve endüstriyel uygulama (Google Pixel, Samsung OnePlus, Xiaomi HyperOS stratejileri) şu senterjiyi doğrular: Donanım maliyeti (RAM GB/$) optimize edilirken, yazılım katmanı (ZRAM zstd + Multi-Gen LRU + Writeback) performans kaybını dengelemektedir. Karar vericiler için yol haritası: 1) Flagship/High-End: ZRAM %50 RAM, zstd, writeback aktif, Multi-Gen LRU tam entegre. 2) Mid-Range: ZRAM %33-40 RAM, lz4, writeback kota ile pasif. 3) Entry/Go Edition: ZRAM %25 RAM, agresif minfree, swappiness=100, writeback kapalı (CPU tasarrufu). Gelecekte CXL/Computational Storage ve ML-based Predictive Memory Management bu dengeyi donanıma kaydıracak; çekirdek ve userspace (LMKD/AMS) sınırı daha da belirsizleşecek, “Unified Memory Pressure Signal” tek bir kontrol döngüsüne toplanacaktır. Tekno Aktif olarak; bu mimariyi takip eden OEM’lerin, RAM BOM maliyetini %15-20 düşürürken UX metriklerini (App Launch, Multitasking Retention, Frame Jitter) koruyabileceğini, hatta iyileştirebileceğini teknik verilerle kanıtlamış bulunuyoruz.