Kesme neden dağıtılmalı?

Bir aygıt işlemcinin ilgilenmesini istediğinde bir kesme isteği (IRQ) üretir. Tek çekirdekli bir makinede hedef bellidir. Çok çekirdekli sistemde ise bütün kesmeleri aynı çekirdeğe göndermek darboğaz yaratır.

Bir çekirdeğin kesmeler için harcadığı yaklaşık işlem yükünü şöyle gösterebiliriz:

Burada $L_i$, $i$ çekirdeğinin yükü; $r_k$, bir kesme kaynağının saniyedeki olay sayısı; $c_k$ ise olayı işleme maliyetidir. Amaç, yükü çekirdekler arasında dengelerken önbellek yerelliğini ve uygulama gecikmesini de korumaktır.

APIC ailesinin oyuncuları

Klasik PIC yalnızca az sayıda IRQ hattını yönetebiliyordu. APIC mimarisi daha fazla kesme vektörü, çoklu işlemci desteği ve esnek hedef seçimi sundu.

xAPIC, hedefleri APIC kimlikleriyle belirlerken kayıtlarına bellek eşlemeli erişim kullanır. Daha yeni x2APIC ise genişletilmiş kimlik alanı ve MSR tabanlı erişim sayesinde çok daha fazla mantıksal işlemciyi destekler.

Hedef çekirdek nasıl seçiliyor?

I/O APIC yönlendirme tablosundaki her kayıt; kesme vektörünü, hedefi, tetikleme biçimini ve teslim modunu içerir. Fixed modunda kesme belirli bir APIC kimliğine gider. Lowest Priority modunda ise uygun hedef kümesi içinden öncelik durumu elverişli olan işlemci seçilebilir.

Modern ağ kartları çoğunlukla MSI-X kullanır. Kart, birden fazla kesme vektörü oluşturabilir; işletim sistemi de her alım-gönderim kuyruğunu farklı çekirdeğe bağlayabilir:

Örneğin ağ kuyruğu 0 çekirdek 2’ye, kuyruk 1 çekirdek 3’e atanabilir. Paket işleme uygulaması da aynı çekirdeklerde çalıştırılırsa veriler önbellekte sıcak kalır.

Linux üzerinde kesme yakınlığı

Linux, her IRQ için bir çekirdek maskesi sunar. Aşağıdaki komutlar önce kesmeleri listeler, ardından 44 numaralı IRQ’yu maske değeri 4, yani çekirdek 2 ile sınırlar:

# IRQ sayaçlarını ve aygıt adlarını görüntüle
grep -E 'CPU|eth|xhci' /proc/interrupts

# 0b0100 maskesi: kesmeyi yalnızca CPU 2 alır
echo 4 | sudo tee /proc/irq/44/smp_affinity

# Çekirdek listesini daha okunabilir biçimde doğrula
cat /proc/irq/44/smp_affinity_list

Gerçek IRQ numarası sistemden sisteme değişir. Ayrıca irqbalance hizmeti yükü otomatik dağıttığından elle yapılan ayarı daha sonra değiştirebilir.

Fare tıklamasından ağ paketine

USB fare tıklaması önce USB denetleyicisine ulaşır. Denetleyici bir kesme üretir; I/O APIC veya MSI mekanizması bunu seçilen Local APIC’e yollar. İşlemci mevcut işini uygun noktada durdurur, kesme işleyicisini çalıştırır ve sonunda EOI bildirerek işlemi tamamlar.

Ağ kartında süreç benzerdir ancak saniyede milyonlarca olay oluşabilir. Bu yüzden MSI-X kuyrukları, kesme birleştirme ve çekirdek yakınlığı kritik hâle gelir. Kısacası APIC yalnızca “hangi çekirdek?” sorusunu yanıtlamaz; sistemin gecikme, verim ve ölçeklenebilirlik dengesini de belirler.

``

Modül mimarisi nasıl çalışır?

Bir çekirdek modülü, kullanıcı alanındaki sıradan uygulamalardan farklı olarak kernel space içinde çalışır. İşletim sisteminin belleğine ve donanım kaynaklarına doğrudan erişebildiği için küçük bir hata bile tüm sistemi durdurabilir. Bu nedenle geliştirmeyi sanal makinede yapmak akıllıcadır.

Modül çekirdeğe yüklendiğinde sembolleri bağlanır, başlangıç fonksiyonu çalıştırılır ve gerekli kaynaklar kaydedilir. Kaldırılırken kaynakların ters sırada serbest bırakılması gerekir. Basitleştirilmiş yaşam döngüsü şöyledir:

Sağlıklı bir kaldırma işleminde sonucun $0$ olması beklenir. Aksi durumda bellek sızıntıları, kullanımda kalan cihazlar veya çökmeler ortaya çıkabilir.

Basit bir karakter cihazı

Aşağıdaki modül, /dev/minidriver adında bir karakter cihazı oluşturur. Kullanıcı cihazı okuduğunda çekirdekten kısa bir mesaj alır. miscdevice arabirimi, ana cihaz numarasını otomatik seçerek örneği sade tutar.

#include <linux/module.h>
#include <linux/miscdevice.h>
#include <linux/fs.h>
#include <linux/uaccess.h>

static const char message[] = "Merhaba, çekirdek!\n";

static ssize_t mini_read(struct file *file, char __user *buffer,
                         size_t length, loff_t *offset)
{
    return simple_read_from_buffer(buffer, length, offset,
                                   message, sizeof(message) - 1);
}

static const struct file_operations mini_fops = {
    .owner = THIS_MODULE,
    .read = mini_read,
};

static struct miscdevice mini_device = {
    .minor = MISC_DYNAMIC_MINOR,
    .name = "minidriver",
    .fops = &mini_fops,
    .mode = 0444,
};

static int __init mini_init(void)
{
    int result = misc_register(&mini_device);

    if (result)
        pr_err("minidriver kaydedilemedi: %d\n", result);
    else
        pr_info("minidriver yüklendi\n");

    return result;
}

static void __exit mini_exit(void)
{
    misc_deregister(&mini_device);
    pr_info("minidriver kaldırıldı\n");
}

module_init(mini_init);
module_exit(mini_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Örnek Geliştirici");
MODULE_DESCRIPTION("Basit karakter cihazı modülü");

file_operations, sistem çağrıları ile sürücü fonksiyonları arasındaki köprüdür. Kullanıcı read() çağırdığında çekirdek mini_read() fonksiyonuna yönelir. simple_read_from_buffer() ise çekirdek belleğindeki veriyi kullanıcı belleğine kontrollü şekilde aktarır; doğrudan işaretçi kopyalamaktan daha güvenlidir.

Derleme ve deneme

Modülü derlemek için aynı dizine şu Makefile dosyasını ekleyin:

obj-m += minidriver.o

all:
	$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Ardından geliştirme başlıklarının kurulu olduğundan emin olarak komutları çalıştırın:

make
sudo insmod minidriver.ko
cat /dev/minidriver
sudo rmmod minidriver
dmesg | tail

insmod modülü doğrudan yüklerken modprobe bağımlılıkları da çözer. Üretim sistemlerinde Secure Boot imzasız modülleri reddedebilir; ayrıca çekirdek API’leri sürümler arasında değişebilir.

Güvenli geliştirme alışkanlıkları

Her tahsisin karşılığında bir temizleme işlemi yazın, kullanıcıdan gelen uzunluk ve adreslere güvenmeyin, kilit gerektiren ortak verileri koruyun ve günlükleri dmesg üzerinden izleyin. Gerçek donanım sürücülerinde kesmeler, DMA, aygıt ağacı ve platform veri yolları devreye girer. Ancak temel ritim değişmez: kaydet, isteği işle, kaynakları eksiksiz bırak ve modülü kaldır.

Bir işlemci çekirdeği bir thread’i durdurup diğerini çalıştırdığında ekranda hiçbir şey kıpırdamaz; ancak donanım ve işletim sistemi küçük bir bavul toplama töreni gerçekleştirir. Yazmaçlar saklanır, yeni yürütme bağlamı yüklenir, adres çevirileri gözden geçirilir ve önbellek düzeni sarsılabilir. Context switch, yararlı iş üretmeyen fakat çoklu görev için kaçınılmaz olan bu sürecin adıdır.

``

Context switch sırasında ne saklanır?

Her thread’in program sayacı, yığın işaretçisi ve genel amaçlı yazmaçları gibi kendine ait bir işlemci durumu bulunur. Zamanlayıcı çalışan thread’i değiştirdiğinde çekirdeğe geçilir; mevcut durum thread’in kontrol bloğuna kaydedilir ve sıradaki thread’in durumu geri yüklenir.

Tipik olarak şu bilgiler işleme katılır:

• Program sayacı ve stack pointer
• Genel amaçlı yazmaçlar
• Bayrak ve durum yazmaçları
• SIMD/FPU durumu
• Zamanlama ve muhasebe bilgileri
• Gerekirse sayfa tablosu bağlamı

Buradaki “kopyalama”, çoğunlukla yazmaçların çekirdek belleğindeki yapılara yazılmasıdır. Modern sistemler, büyük SIMD durumunu her geçişte körlemesine taşımak yerine tembel veya donanım destekli yöntemler kullanabilir.

Bir uygulamanın toplam çalışma süresini basitçe şöyle düşünebiliriz:

Burada $N_{cs}$ context switch sayısıdır. Doğrudan maliyet, çekirdek kodu ve durum kaydetme süresidir. Dolaylı maliyet ise soğuyan cache, bozulan branch predictor geçmişi ve TLB kayıplarıdır. Çoğu zaman asıl canavar ikinci tarafta saklanır.

TLB neden önemlidir?

TLB, sanal adreslerin fiziksel adreslere çevrilmiş sonuçlarını tutan küçük ve hızlı bir önbellektir. Farklı süreçler farklı adres uzaylarına sahip olduğundan süreçler arası geçiş, eski çevirilerin geçersiz kılınmasını gerektirebilir. Bir sonraki bellek erişiminde TLB miss oluşursa işlemci sayfa tablolarını yürümek zorunda kalır.

Bununla birlikte “her context switch TLB’yi tamamen temizler” demek günümüzde doğru değildir. PCID ve ASID gibi etiketleme mekanizmaları, farklı adres uzaylarının TLB kayıtlarını birlikte koruyabilir. Aynı süreçteki thread’ler zaten adres uzayını paylaştığı için aralarındaki geçiş genellikle daha ucuzdur.

Maliyeti ölçmek

Aşağıdaki Linux örneği iki thread arasında eventfd kullanarak kontrollü biçimde sinyal dolaştırır. Amaç gerçek uygulamayı taklit etmek değil, çok sayıda uyandırma ve zamanlama geçişinin toplam süresini gözlemlemektir.

#include <pthread.h>
#include <sys/eventfd.h>
#include <stdint.h>
#include <unistd.h>

int a, b;
const int tekrar = 100000;

void *worker(void *arg) {
    uint64_t x;
    for (int i = 0; i < tekrar; i++) {
        read(a, &x, sizeof(x));
        write(b, &x, sizeof(x));
    }
    return NULL;
}

int main(void) {
    uint64_t x = 1;
    pthread_t t;
    a = eventfd(0, 0);
    b = eventfd(0, 0);
    pthread_create(&t, NULL, worker, NULL);

    for (int i = 0; i < tekrar; i++) {
        write(a, &x, sizeof(x));
        read(b, &x, sizeof(x));
    }
    pthread_join(t, NULL);
}

Program perf stat -e context-switches,cycles,instructions,cache-misses ./a.out ile çalıştırılabilir. Ölçüm sırasında CPU frekansı, çekirdek göçleri ve arka plan yükü sonuçları etkileyebileceğinden deneyi birkaç kez tekrarlamak gerekir.

Optimizasyon stratejileri

İlk hedef thread sayısını körlemesine artırmak değil, çalıştırılabilir thread sayısını çekirdek sayısıyla uyumlu tutmaktır. Thread pool kullanmak, kısa işler için sürekli thread oluşturup yok etmeyi önler. Küçük görevleri gruplamak zamanlayıcıya yapılan başvuruları azaltır.

CPU affinity, aynı thread’i belirli çekirdeklere bağlayarak cache yerelliğini koruyabilir; fakat dengesiz yükte boş çekirdeklerden yararlanmayı zorlaştırabilir. Kilit rekabetini azaltmak, gereksiz uyandırmaları engellemek ve bloklayan I/O için asenkron modeller kullanmak da etkilidir.

Sonuç olarak context switch tek başına kötü değildir; gereksiz ve aşırı olduğunda pahalıdır. En iyi optimizasyon, nanosanileri kovalamadan önce perf, profiler ve zamanlayıcı metrikleriyle gerçek darboğazı ölçmektir. Görünmez maliyet ancak ölçüldüğünde görünür olur.

``

eBPF tam olarak nedir?

eBPF, kullanıcı alanında hazırlanan programların Linux çekirdeğindeki belirli kancalara yüklenmesini sağlayan bir çalışma ortamıdır. İsmindeki BPF, tarihsel olarak “Berkeley Packet Filter” anlamına gelse de teknoloji bugün ağ paketlerinin çok ötesine uzanır: sistem çağrıları, süreçler, dosya erişimleri ve performans olayları da izlenebilir.

“Çekirdeğe dokunmadan” ifadesi, kodun çekirdek dışında çalıştığı anlamına gelmez. eBPF programı çekirdek bağlamında çalışır; ancak çekirdek kaynak kodunu değiştirmeye veya özel bir modül yüklemeye gerek bırakmaz. Program yüklenmeden önce verifier tarafından incelenir. Geçersiz bellek erişimi, güvensiz işaretçi kullanımı veya sonlanmama riski varsa program reddedilir.

XDP neden bu kadar hızlı?

XDP, yani eXpress Data Path, paketi ağ sürücüsünden gelir gelmez işleyebilir. Paket henüz sk_buff yapısına dönüştürülmeden karar verildiği için ayırma, kopyalama ve ağ yığını maliyetleri azaltılır.

Bir paketin yaklaşık işlem maliyetini şöyle düşünebiliriz:

XDP özellikle $T_{ayrıştırma}$ ve $T_{yönlendirme}$ bileşenlerini küçültür. Program paketi kabul etmek için XDP_PASS, düşürmek için XDP_DROP, başka arayüze göndermek için XDP_REDIRECT döndürebilir.

Aşağıdaki orta düzey örnek, IPv4 UDP paketlerini erken aşamada düşürür:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int drop_udp(struct xdp_md *ctx)
{
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return XDP_ABORTED;

    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_ABORTED;

    return ip->protocol == IPPROTO_UDP ? XDP_DROP : XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

Sınır kontrolleri yalnızca iyi programlama alışkanlığı değildir; verifier, data_end kontrolü bulunmayan paket erişimini kabul etmez. Kod Clang ile eBPF bytecode’una çevrilip bir arayüze bağlanabilir:

clang -O2 -g -target bpf -c filter.c -o filter.o
sudo ip link set dev eth0 xdp obj filter.o sec xdp
sudo ip link set dev eth0 xdp off

İlk komut programı derler, ikincisi eth0 arayüzüne yükler, sonuncusu ise bağlantıyı kaldırır. Uzaktan bağlı bir sunucuda bütün UDP trafiğini düşürmeden önce DNS ve VPN kullanımını düşünmek iyi fikirdir; aksi hâlde güvenlik demosu hızla bağlantı kesme demosuna dönüşebilir.

Haritalar ve gözlemlenebilirlik

eBPF haritaları, çekirdek ve kullanıcı alanı arasında paylaşılan anahtar-değer depolarıdır. IP başına paket sayacı tutmak, engelli adresleri dinamik olarak güncellemek veya CPU başına istatistik toplamak için kullanılabilirler. Üretimde C ile doğrudan uğraşmak yerine libbpf, BCC, bpftrace, Cilium ve Rust tabanlı Aya gibi araçlardan yararlanılabilir.

TC kancaları paket değişikliği ve trafik şekillendirme konusunda daha esnekken XDP mümkün olan en erken kararı hedefler. Sonuç olarak eBPF, klasik çekirdek modüllerinin bütün risklerini üstlenmeden çekirdek hızına yaklaşan, programlanabilir bir ağ güvenliği ve izleme katmanı sunar.

``

C10K problemi neden ortaya çıktı?

Klasik yaklaşımda her bağlantı için ayrı süreç veya iş parçacığı oluşturulurdu. Bu model anlaşılır olsa da bağlantı sayısı yükseldiğinde bellek tüketimi, bağlam değiştirme ve zamanlayıcı yükü büyür. Yaklaşık maliyeti şöyle düşünebiliriz:

Burada $N$ bağlantı sayısını, $S$ ise her iş parçacığının yığın ve yönetim maliyetini temsil eder. Her iş parçacığı yalnızca 1 MB yığın ayırsa 10.000 bağlantı teorik olarak 10 GB adres alanı isteyebilir. Üstelik işlemci, iş yapanlardan çok bekleyen iş parçacıkları arasında dolaşabilir.

select ve poll daha az iş parçacığıyla çalışmayı mümkün kılsa da her çağrıda izlenen tanımlayıcıların taranması gerekir. Bu davranış kabaca $O(N)$ maliyetlidir. epoll ve kqueue ise yalnızca durumu değişen olayları döndürerek maliyeti pratikte hazır olay sayısına, yani $O(K)$ düzeyine yaklaştırır.

epoll ve kqueue karşılaştırması

Level-triggered kullanımda veri okunabilir kaldığı sürece bildirim tekrar gelir. Bu, unutkan programcılar için daha güvenlidir. Edge-triggered kullanımda ise yalnızca durum değişiminde bildirim alınır. Daha az uyarı üretir ancak soketin EAGAIN sonucuna kadar tamamen boşaltılması gerekir; aksi hâlde veri kuyrukta sessizce bekleyebilir.

Linux üzerinde epoll akışı

Aşağıdaki C kodu, bir epoll örneği oluşturup dinleme soketini takip listesine ekler:

int epfd = epoll_create1(EPOLL_CLOEXEC);

struct epoll_event ev = {0};
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = server_fd;

epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);

struct epoll_event events[256];
int count = epoll_wait(epfd, events, 256, -1);

for (int i = 0; i < count; i++) {
    handle_event(events[i].data.fd, events[i].events);
}

EPOLLIN, okunabilir veri bulunduğunu; EPOLLET ise edge-triggered çalışma istendiğini belirtir. Gerçek bir sunucuda soketler non-blocking yapılmalı, accept ve read işlemleri EAGAIN görülene kadar döngüyle sürdürülmelidir.

BSD tarafında kqueue

kqueue aynı fikri filtrelerle daha genel hâle getirir:

int kq = kqueue();
struct kevent change;

EV_SET(&change, server_fd, EVFILT_READ,
       EV_ADD | EV_ENABLE, 0, 0, NULL);
kevent(kq, &change, 1, NULL, 0, NULL);

struct kevent events[256];
int count = kevent(kq, NULL, 0, events, 256, NULL);

for (int i = 0; i < count; i++) {
    handle_event((int)events[i].ident, events[i].filter);
}

EVFILT_READ okunabilirliği izler. Aynı mekanizma EVFILT_TIMER ile zamanlayıcıları, EVFILT_SIGNAL ile sinyalleri ve EVFILT_PROC ile süreç değişimlerini de takip edebilir. Bu bütünlük, kqueue’nun en şık tarafıdır.

Hangisini seçmeli?

Seçim çoğunlukla performanstan önce platform tarafından yapılır: Linux’ta epoll, BSD ve macOS’ta kqueue doğal tercihtir. Nginx, libuv, Tokio ve benzeri sistemler bu ayrıntıları soyutlayabilir. Yine de sihirli değnek yoktur; yavaş istemciler, geri basınç, zaman aşımı, bağlantı başına bellek ve adil görev dağıtımı ayrıca tasarlanmalıdır.

Sonuçta C10K’yı aşmanın sırrı, her bağlantıya çalışan tahsis etmek değil, hazır olana çalışacak zaman vermektir. epoll ve kqueue farklı lehçelerde konuşsa da aynı cümleyi kurar: Boşta bekleme, olay gelince harekete geç!

FUSE tam olarak nedir?

FUSE, yani Filesystem in Userspace, dosya sistemi mantığının kullanıcı alanında çalışan normal bir program tarafından uygulanmasını sağlayan Linux altyapısıdır. Uygulamalar yine open, read, write ve stat gibi standart sistem çağrılarını kullanır. Çekirdekteki FUSE sürücüsü bu istekleri bizim sürecimize iletir, cevabı alır ve uygulamaya döndürür.

Akış kabaca şöyledir:

1. Kullanıcı /mnt/ozel/merhaba.txt dosyasını okur.
2. İşletim sistemi isteği FUSE sürücüsüne gönderir.
3. FUSE, Python programımızdaki read() metodunu çağırır.
4. Metodun ürettiği veri kullanıcıya teslim edilir.

Bir işlemin toplam gecikmesini basitçe $T = T_{kernel} + T_{iletisim} + T_{uygulama}$ şeklinde düşünebiliriz. Kullanıcı alanına geçiş ek maliyet oluşturduğu için FUSE her senaryoda yerel dosya sistemleri kadar hızlı değildir; fakat geliştirme kolaylığı çoğu özel proje için daha değerlidir.

Python ile çalışan küçük bir örnek

Ubuntu tabanlı bir sistemde gerekli paketleri şu şekilde kurabiliriz:

sudo apt install fuse3 libfuse3-dev
python3 -m pip install fusepy
mkdir -p /tmp/benimfs

Aşağıdaki dosya sistemi yalnızca merhaba.txt isimli sanal bir dosya sunar. Dosyanın fiziksel diskte bulunması gerekmez; içerik Python tarafından anlık üretilir.

from fuse import FUSE, Operations
import errno
import os

class BenimFS(Operations):
    mesaj = b"Merhaba, bu veri sanal dosya sisteminden geliyor!\n"

    def getattr(self, path, fh=None):
        if path == "/":
            return {
                "st_mode": 0o40555,
                "st_nlink": 2
            }

        if path == "/merhaba.txt":
            return {
                "st_mode": 0o100444,
                "st_nlink": 1,
                "st_size": len(self.mesaj)
            }

        raise OSError(errno.ENOENT, os.strerror(errno.ENOENT))

    def readdir(self, path, fh):
        return [".", "..", "merhaba.txt"]

    def open(self, path, flags):
        if path != "/merhaba.txt":
            raise OSError(errno.ENOENT, "Dosya bulunamadı")
        if flags & (os.O_WRONLY | os.O_RDWR):
            raise OSError(errno.EACCES, "Dosya salt okunur")
        return 0

    def read(self, path, size, offset, fh):
        return self.mesaj[offset:offset + size]

if __name__ == "__main__":
    FUSE(BenimFS(), "/tmp/benimfs", foreground=True)

getattr() dosyanın türünü, izinlerini ve boyutunu bildirir. readdir() dizin listesini üretir. open() erişim kurallarını denetlerken read() istenen aralıktaki baytları döndürür. Programı python3 benimfs.py ile çalıştırdıktan sonra başka bir terminalde cat /tmp/benimfs/merhaba.txt komutu kullanılabilir. Ayırmak için fusermount3 -u /tmp/benimfs yeterlidir.

Tasarımda dikkat edilmesi gerekenler

Gerçek bir projede eşzamanlı erişim, önbellekleme, dosya tanıtıcıları, kullanıcı kimlikleri ve hata kodları hesaba katılmalıdır. read() metodunun tüm içeriği değil, yalnızca offset ile başlayan size baytı döndürmesi özellikle önemlidir. Aksi hâlde büyük dosyalarda beklenmedik sonuçlar oluşabilir.

FUSE; prototipler, eğitim araçları, arşiv görüntüleyicileri ve uzak depolama istemcileri için güçlü bir oyun alanıdır. Çekirdeğe dalmadan işletim sisteminin dosya soyutlamasını kullanabilir, hatta bir REST API’yi klasör ve dosyalardan oluşan doğal bir arayüze dönüştürebilirsiniz.

Bir işletim sistemi çekirdeği için boş RAM, gelişigüzel dağıtılabilecek dev bir tarla değildir. Sürücüler, süreçler ve çekirdek veri yapıları sürekli farklı büyüklüklerde fiziksel bellek ister. Buddy bellek yönetimi, bu talepleri hızlı karşılamak için belleği ikinin kuvvetleri büyüklüğündeki bloklara ayırır; gerektiğinde blokları ikiye böler, serbest bırakıldıklarında ise yeniden birleştirir. ``

Buddy sisteminin temel fikri

Buddy allocator, yönetilen bellek bölgesini genellikle büyüklüğü $2^N$ olan büyük bir blok olarak kabul eder. Bir istek geldiğinde, isteği karşılayabilecek en küçük ikinin kuvveti seçilir.

Örneğin 13 KB bellek isteniyorsa uygun blok büyüklüğü:

Sistemde yalnızca 64 KB’lık boş bir blok bulunduğunu düşünelim. Çekirdek bu bloğu sırasıyla böler:

• 64 KB → iki adet 32 KB
• Bir 32 KB → iki adet 16 KB
• 16 KB bloklardan biri isteğe verilir
• Kullanılmayan bloklar boş listelerde tutulur

Bir bloğun bölünmesiyle oluşan eşit büyüklükteki iki parçaya buddy, yani eş blok denir. Bu iki bloktan biri serbest bırakıldığında diğeri de boşsa tekrar birleşebilirler.

Siparişler ve boş listeler

Her blok büyüklüğü bir order ile temsil edilir. Sayfa büyüklüğü 4 KB ise order 0 bir sayfa, order 1 iki sayfa taşır:

Çekirdek, her order için ayrı bir boş blok listesi tutar. İstenen order boşsa daha üst order’lardan blok aranır. Bulunan büyük blok, hedef boyuta ulaşılıncaya kadar parçalanır. Böylece tüm RAM’i taramak yerine birkaç liste üzerinde işlem yapılır.

Eş blok nasıl bulunur?

Buddy yaklaşımının en zarif numarası adres hesabıdır. Boyutu $2^k$ olan bir bloğun başlangıç adresi biliniyorsa buddy adresi şu şekilde hesaplanabilir:

Buradaki $\oplus$ bit düzeyinde XOR işlemidir. İlgili boyut bitini değiştirmek, bloğun eşini doğrudan bulur. Böylece pahalı aramalar yerine hızlı bir adres hesabı yeterli olur.

size_t buddy_address(size_t address, unsigned int order,
                     size_t page_size) {
    size_t block_size = page_size << order;
    return address ^ block_size;
}

Bu örnek, sayfa boyutunu order kadar sola kaydırarak blok büyüklüğünü hesaplar ve XOR ile eş bloğun adresini üretir. Gerçek çekirdeklerde fiziksel sayfa numaraları, bölgeler ve ek güvenlik kontrolleri de hesaba katılır.

Bölme ve birleştirme döngüsü

Serbest bırakma sırasında allocator aynı order’daki buddy bloğu kontrol eder. Buddy boşsa iki blok birleşir ve bir üst order’a taşınır. Ardından yeni büyük bloğun buddy’si kontrol edilir. Bu işlem birleşme mümkün olmayana kadar sürer.

free(block, order):
    while order < MAX_ORDER:
        buddy = find_buddy(block, order)
        if buddy kullanımda ise:
            break
        buddy'yi boş listesinden çıkar
        block = adresi daha küçük olan blok
        order = order + 1
    block'u ilgili boş listeye ekle

Buddy sistemi parçalanmayı tamamen yok etmez. 17 KB’lık istek 32 KB blok kullanacağından 15 KB iç parçalanma oluşur. Buna karşılık standart blok boyutları ve hızlı birleşme, dış parçalanmayı azaltır. Linux gibi sistemler bu yöntemi küçük nesneler için kullanılan slab veya SLUB allocator’larla birlikte çalıştırır. Kısacası buddy allocator, RAM’i kusursuz değil; hızlı, öngörülebilir ve çekirdek için yönetilebilir biçimde parseller.

``

Page cache nedir?

İşletim sistemi, depolama aygıtındaki dosyaları doğrudan uygulamaların yönetmesine izin vermez. Uygulama bir dosya istediğinde çekirdek, veriyi belirli büyüklükteki bellek sayfaları hâlinde okur. Okunan sayfalar yalnızca programa verilmez; aynı zamanda RAM içindeki page cache alanında tutulur.

Aynı dosya yeniden istendiğinde çekirdek önce önbelleği kontrol eder. Gerekli sayfalar RAM’deyse diske erişmeden sonucu döndürür. Buna cache hit, verinin bulunamayıp diskten okunmasına ise cache miss denir.

Basitleştirilmiş toplam erişim süresi şöyle düşünülebilir:

Buradaki $H$, önbellek isabet oranıdır. $H$ değeri 1’e yaklaştıkça ortalama erişim süresi RAM hızına yaklaşır. Küçük görünen bir isabet oranı artışı bile yoğun dosya kullanan sunucularda büyük performans farkı yaratabilir.

“Boş RAM” neden gerçekten boş değildir?

Görev yöneticisinde RAM’in büyük bölümünün kullanıldığını görmek her zaman sorun anlamına gelmez. Modern işletim sistemleri kullanılmayan belleği boş bırakmak yerine dosya önbelleği olarak değerlendirir. Çünkü kullanılmayan RAM, performans açısından kaçırılmış bir fırsattır.

Bir uygulama daha fazla belleğe ihtiyaç duyduğunda önbellekteki temiz sayfalar kolayca bırakılabilir. Bu nedenle page cache, uygulamaların belleğini “çalmaz”; ihtiyaç ortaya çıkana kadar boş kapasiteyi ödünç alır.

Linux çıktılarındaki free, buff/cache ve özellikle available değerleri bu yüzden birlikte değerlendirilmelidir:

# Belleğin uygulamalar ve önbellek arasında nasıl dağıldığını gösterir.
free -h

# Bir dosyayı okuyarak gerçek süreyi ölçer.
time cat buyuk-dosya.bin > /dev/null

# Aynı komut ikinci kez çalıştırıldığında veri büyük olasılıkla cache'tedir.
time cat buyuk-dosya.bin > /dev/null

İkinci çalıştırmanın daha hızlı olması, dosyanın değiştiği veya cat programının özel bir numara yaptığı anlamına gelmez. İlk komut dosya sayfalarını RAM’e taşımış, ikinci komut ise hazır bulunan sayfaları kullanmıştır. Dosya RAM kapasitesinden büyükse veya sistem yoğun bellek baskısı altındaysa fark azalabilir.

Yazma işlemlerinde de görev alır mı?

Evet. Bir uygulama dosyaya yazdığında veri çoğu zaman önce bellekteki sayfalara aktarılır. Değiştirilmiş ve henüz diske gönderilmemiş sayfalara dirty page denir. Çekirdek bunları daha sonra toplu biçimde diske yazar. Böylece uygulama her küçük değişiklik için fiziksel disk işlemini beklemez.

Bu yaklaşım performansı artırsa da elektrik kesintisi gibi durumlarda henüz kalıcı depolamaya ulaşmamış veriler kaybolabilir. Veritabanları bu nedenle fsync benzeri çağrılarla kritik verinin diske ulaştığından emin olur.

Page cache her şeyi hızlandırır mı?

Page cache sihirli değildir. İlk okuma yine depolama aygıtının hızına bağlıdır. Çok büyük veri kümeleri önbelleğe sığmayabilir; başka uygulamalar da sık kullanılan sayfaları dışarı itebilir. Ayrıca bazı veritabanları ve özel uygulamalar, kendi önbelleklerini yönetmek için doğrudan I/O kullanabilir.

Yine de günlük kullanımda programların hızlı açılması, kaynak kodlarının çabuk derlenmesi ve aynı videonun tekrar akıcı oynatılması çoğunlukla bu görünmez yardımcı sayesinde gerçekleşir. Kısacası yüksek RAM kullanımı her zaman kötü değildir: İşletim sistemi belleği dosyalarla dolduruyorsa, RAM’iniz tembellik etmek yerine gelecekteki disk okumalarını hızlandırıyordur.

``

İşlemci neden önbelleğe ihtiyaç duyar?

CPU ile RAM aynı hızda çalışmaz. İşlemci bir komutu birkaç çevrimde tamamlayabilirken RAM erişimi yüzlerce çevrim sürebilir. Bu farkı azaltmak için işlemci ile RAM arasına küçük fakat hızlı önbellek katmanları yerleştirilir.

Aranan veri önbellekte bulunursa cache hit, bulunamazsa cache miss oluşur. Basitleştirilmiş ortalama erişim süresi şöyle düşünülebilir:

Burada $h$ cache hit oranıdır. RAM çok daha yavaş olduğundan, $h$ değerindeki küçük bir artış bile toplam süreyi ciddi biçimde azaltabilir.

Mekânsal ve zamansal yerellik

Önbellek RAM’den tek bir değişken getirmez; genellikle 64 baytlık bir cache line taşır. Bir elemana eriştiğimizde komşu elemanlar da gelir. Ardışık elemanları kullanmak mekânsal yerellik, aynı veriyi kısa süre içinde tekrar kullanmak ise zamansal yerellik sağlar.

C ve C++ gibi dillerde iki boyutlu diziler satır öncelikli saklanır. Bu nedenle döngü sırası önemlidir:

#define N 2048
int matrix[N][N];
long long toplam = 0;

// Cache dostu: Bellekte ardışık elemanlar okunur.
for (int i = 0; i < N; i++) {
    for (int j = 0; j < N; j++) {
        toplam += matrix[i][j];
    }
}

İç döngüde j değiştiği için matrix[i][j] elemanları art arda okunur. Döngüleri ters çevirmek ise her erişimde farklı bir satıra sıçrayabilir:

// Cache açısından zayıf: Büyük adımlarla bellekte gezinir.
for (int j = 0; j < N; j++) {
    for (int i = 0; i < N; i++) {
        toplam += matrix[i][j];
    }
}

Her iki kod da aynı matematiksel sonucu üretir ve zaman karmaşıklıkları $O(N^2)$ olur. Buna rağmen gerçek çalışma süreleri dramatik biçimde farklılaşabilir. Big-O, bellek erişim maliyetini tek başına anlatmaz.

Veri yapısının dizilişi: AoS ve SoA

Bir oyundaki parçacıkları düşünelim:

struct Parca {
    float x, y, z;
    float hiz;
    int renk;
};

struct Parca parcalar[1000000];

Bu yaklaşım Array of Structures (AoS) olarak adlandırılır. Yalnızca konumları güncelliyorsak kullanılmayan renk gibi alanlar da cache line içine taşınır. Alternatif Structure of Arrays (SoA) düzeninde alanlar ayrılır:

struct Parcalar {
    float x[1000000];
    float y[1000000];
    float z[1000000];
    float hiz[1000000];
    int renk[1000000];
};

Büyük veriyi bloklar hâlinde işlemek

Matris çarpımı gibi algoritmalarda veri L1 veya L2’ye sığmayabilir. Blocking ya da tiling, problemi önbelleğe sığan küçük parçalara ayırır:

const int B = 32;

for (int ii = 0; ii < N; ii += B)
    for (int kk = 0; kk < N; kk += B)
        for (int i = ii; i < ii + B; i++)
            for (int k = kk; k < kk + B; k++)
                sonuc[i] += matrix[i][k] * vektor[k];

Blok boyutu donanıma ve veri tipine göre ölçülerek seçilmelidir. Gereğinden büyük bloklar önbellekten taşar; çok küçük bloklar ise döngü yönetimi maliyetini artırır.

Sonuç olarak ardışık erişim, tekrar kullanılan veriyi yakın tutma, uygun veri düzeni ve bloklama cache hit oranını yükseltir. En doğru optimizasyon için tahminde bulunmak yerine perf, Valgrind Cachegrind veya işlemci performans sayaçlarıyla cache miss değerlerini ölçmek gerekir. Çünkü hızlı kod yalnızca daha az işlem yapan değil, işlemciyi verisiz bırakmayan koddur.

Cgroups neyi çözer?

Cgroups, süreçleri gruplandırır ve CPU, bellek, disk G/Ç ya da süreç sayısı gibi kaynakları bu gruplar üzerinden denetler. Namespace’ler bir konteynerin neyi görebildiğini, cgroups ise ne kadar tüketebildiğini belirler. Dolayısıyla ikisi tamamlayıcıdır: namespace izolasyon perdesiyken cgroups kaynak bütçesidir.

Bir grubun CPU kullanım oranı basitçe

ile düşünülebilir. Burada $Q$ izin verilen CPU süresi, $P$ ise periyottur. Örneğin cpu.max dosyasına 50000 100000 yazılması, grubun her 100 milisaniyede en fazla 50 milisaniye CPU kullanabilmesi, yani yaklaşık $R=0.5$ CPU kapasitesi anlamına gelir.

v1 neden yorucuydu?

Cgroups v1’de her denetleyici bağımsız bir hiyerarşiye bağlanabiliyordu. Aynı süreç CPU ağacında bir grupta, bellek ağacında başka bir grupta bulunabiliyordu. Esneklik gibi görünen bu model; Docker, systemd ve Kubernetes gibi araçlar aynı makinede çalıştığında yönetim karmaşasına, belirsiz yetki devrine ve tutarsız kaynak davranışlarına yol açıyordu.

Birleşik hiyerarşi nasıl çalışır?

v2 çoğunlukla /sys/fs/cgroup altında tek bir ağaç sunar. Bir sürecin kimliği cgroup.procs, kullanılabilir denetleyiciler cgroup.controllers, alt gruplara aktarılacak denetleyiciler ise cgroup.subtree_control üzerinden yönetilir.

# Sistemde etkin olan v2 denetleyicilerini gösterir.
cat /sys/fs/cgroup/cgroup.controllers

# Yeni bir uygulama grubu oluşturur.
sudo mkdir /sys/fs/cgroup/demo

# Kabuğun PID'sini gruba taşır.
echo $$ | sudo tee /sys/fs/cgroup/demo/cgroup.procs

v2’nin önemli kurallarından biri no internal process constraint ilkesidir. Kaynak denetleyicileri alt gruplara dağıtan bir cgroup, normalde aynı anda doğrudan süreç barındırmaz. Başka bir deyişle dallar organizasyon, yapraklar iş yükü içindir. Bu kural, ebeveyn ve çocuk gruplar arasında kaynak hesabının bulanıklaşmasını önler.

Bellek, CPU ve süreç sınırları

Bellek tarafında memory.max kesin tavanı, memory.high ise çekirdeğin agresif geri kazanım uygulamaya başlayacağı yumuşak eşiği ifade eder. Böylece uygulamayı anında öldürmeden önce baskı oluşturmak mümkündür. memory.current mevcut tüketimi gösterirken memory.events, OOM gibi olayları sayar.

# Kesin bellek limitini 512 MiB yapar.
echo 536870912 | sudo tee /sys/fs/cgroup/demo/memory.max

# Yaklaşık yarım CPU ve en fazla 100 süreç tanımlar.
echo '50000 100000' | sudo tee /sys/fs/cgroup/demo/cpu.max
echo 100 | sudo tee /sys/fs/cgroup/demo/pids.max

CPU paylaşım önceliği için v1’deki cpu.shares yerine daha anlaşılır bir aralığa sahip cpu.weight kullanılır. G/Ç denetimi de io.max ve io.weight gibi tutarlı adlarla sunulur.

Docker açısından anlamı

Docker’daki --memory, --cpus ve --pids-limit seçenekleri sonuçta bu dosyalara dönüştürülür. Modern systemd sürümleri de servisleri cgroup ağacında doğal olarak düzenler. Tek hiyerarşi sayesinde orkestratör, çalışma zamanı ve init sistemi aynı kaynak ağacını paylaşabilir; “bu süreci aslında kim yönetiyor?” bilmecesi büyük ölçüde ortadan kalkar.

Cgroups v2 yalnızca temizlenmiş bir arayüz değildir. Tutarlı muhasebe, güvenli yetki devri, gelişmiş bellek baskısı ve sade hiyerarşi sayesinde konteyner izolasyonunu daha sağlam bir çekirdek sözleşmesine dönüştürür. Kısacası v1 kaynaklara ayrı ayrı kilit vuruyordu; v2 ise bütün binaya düzenli bir erişim planı çiziyor.