``

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.

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.

``

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.

``

Fikir nereden çıktı?

“Öğrenmeyi öğrenme” düşüncesi yapay zekâdan daha eskidir. Psikoloji, insanların önceki deneyimlerinden yararlanarak yeni becerileri daha hızlı kazandığını uzun süredir inceliyordu. Makine öğrenmesinde ise erken dönem çalışmalar, algoritmaların kendi öğrenme kurallarını ayarlayıp ayarlayamayacağı sorusuna odaklandı.

1990’larda sinir ağlarının ağırlık güncellemelerini başka ağlarla yönetme fikri belirginleşti. 2000’lerde çoklu görev öğrenmesi ve aktarım öğrenmesi güçlü temeller sağladı. 2010’ların ortasında derin öğrenme, büyük veri kümeleri ve GPU’larla birleşince meta-learning uygulanabilir hâle geldi. 2016 tarihli Matching Networks ve 2017’de yayımlanan MAML, alanın en etkili dönüm noktaları arasında yer aldı.

Görevler üzerinden öğrenmek

Normal eğitimde veri noktaları örneklenir. Meta-learning eğitiminde ise görevler örneklenir. Her görev genellikle iki parçaya ayrılır:

• Destek kümesi: Modelin göreve uyum sağladığı az sayıdaki örnek.
• Sorgu kümesi: Uyumun gerçekten işe yarayıp yaramadığını ölçen örnekler.

Bir görev $T_i$ için destek kaybı $L_{S_i}$ olsun. Modelin başlangıç parametreleri $θ$ ise tek adımlık uyarlama şöyle yazılabilir:

Burada $α$ iç döngünün öğrenme oranıdır. Meta-model, uyarlanmış parametrelerin sorgu kümelerindeki toplam hatasını azaltmaya çalışır:

İşin sihri burada yatar: Sistem yalnızca doğru cevabı değil, birkaç gradyan adımından sonra iyi sonuç verecek bir başlangıç noktası öğrenir. MAML’ın modelden bağımsız sayılmasının nedeni de bu fikrin sınıflandırma, regresyon veya pekiştirmeli öğrenme gibi farklı alanlara uygulanabilmesidir.

Üç ana meta-learning ailesi

Metrik tabanlı yöntemlerde her sınıfın prototipi hesaplanabilir. $k$ sınıfına ait destek temsillerinin ortalaması:

Yeni örnek, temsili hangi $c_k$ noktasına daha yakınsa o sınıfa atanır. Bir bakıma model, “Bu fotoğraf hangi aile albümüne daha çok benziyor?” diye sorar.

MAML mantığının küçük bir kod karşılığı

Aşağıdaki PyTorch taslağı, tek görev için iç güncelleme yapar ve sorgu kaybını hesaplar. create_graph=True, dış döngünün iç güncelleme üzerinden türev alabilmesini sağlar:

import torch
from torch.func import functional_call

support_logits = model(x_support)
support_loss = loss_fn(support_logits, y_support)

params = dict(model.named_parameters())
grads = torch.autograd.grad(
    support_loss,
    params.values(),
    create_graph=True
)

fast_params = {
    name: param - inner_lr * grad
    for (name, param), grad in zip(params.items(), grads)
}

query_logits = functional_call(model, fast_params, (x_query,))
outer_loss = loss_fn(query_logits, y_query)

optimizer.zero_grad()
outer_loss.backward()
optimizer.step()

Gerçek uygulamada bu işlem birçok görev için tekrarlanır ve sorgu kayıpları ortalanır. Hesaplama maliyeti özellikle ikinci dereceden türevler nedeniyle yükselebilir; First-Order MAML ve Reptile gibi yöntemler bu yükü azaltmayı hedefler.

Neden önemli?

Meta-learning; nadir hastalıkların sınıflandırılması, yeni robot hareketleri, kişiselleştirilmiş öneriler ve az kaynaklı diller gibi verinin pahalı olduğu alanlarda değerlidir. Yine de görev dağılımı kötü seçilirse model yeni koşullara uyum sağlayamaz. Kısacası öğrenmeyi öğrenen bir sistem de öğretmeninin hazırladığı müfredat kadar iyidir. Meta-learning’in büyük vaadi, her şeyi bilen modeller değil; bilmediği bir şeyle karşılaştığında ne yapacağını daha çabuk anlayan modeller üretmesidir.

``

Temel fark: Uyku mu, aktif bekleme mi?

Bir mutex alınamıyorsa bekleyen iş parçacığı çoğunlukla işletim sistemi tarafından uyutulur. Böylece işlemci başka işler çalıştırabilir. Ancak uyutma ve yeniden uyandırma; sistem çağrıları, zamanlayıcı müdahalesi ve bağlam değişimi gibi maliyetler doğurur.

Bir spinlock ise iş parçacığını uyutmaz. İş parçacığı kilidi tekrar tekrar kontrol ederek işlemci üzerinde aktif kalır. Kilit birkaç nanosaniye sonra açılacaksa bu yaklaşım oldukça hızlıdır. Bekleme uzarsa işlemci zamanı ve enerji boşa harcanır.

Maliyetin matematiği

Spinlock seçiminin mantıklı olması için bekleme maliyetinin uyutma maliyetinden küçük olması beklenir. Basitleştirilmiş karar koşulu şöyledir:

Kilit ortalama $T_k$ süre tutuluyor ve kilidi dolu bulma olasılığı $P_c$ ise spinlock için yaklaşık bekleme maliyeti $P_c \times T_k$ olarak düşünülebilir. Mutex tarafında ise bağlam değiştirme maliyeti devreye girer. Modern sistemlerde bu değerler sabit değildir; çekirdek sayısı, önbellek mimarisi ve sistem yükü sonucu değiştirir.

Spinlock yalnızca döngü maliyeti de değildir. Kilit değişkeninin farklı çekirdeklerin önbellekleri arasında taşınması cache coherence trafiği oluşturur. Çok sayıda çekirdek aynı bellek satırını izliyorsa küçücük bir atomik değişken, sistemin en popüler dedikodu konusu hâline gelebilir.

C++ ile iki yaklaşım

Aşağıdaki basit spinlock, atomic_flag kullanarak kilidi atomik biçimde almaya çalışır. yield, işletim sistemine başka bir iş parçacığını çalıştırabileceğini söyler; fakat kilidi gerçek anlamda uyuyan bir mutex hâline getirmez.

#include <atomic>
#include <thread>

class SpinLock {
    std::atomic_flag locked = ATOMIC_FLAG_INIT;

public:
    void lock() {
        while (locked.test_and_set(std::memory_order_acquire)) {
            std::this_thread::yield();
        }
    }

    void unlock() {
        locked.clear(std::memory_order_release);
    }
};

Aynı kritik bölüm standart mutex ile daha güvenli ve okunaklı biçimde korunabilir:

#include <mutex>

std::mutex mutex;
int counter = 0;

void increment() {
    std::lock_guard<std::mutex> guard(mutex);
    ++counter; // Paylaşılan veriyi güvenle günceller.
}

std::lock_guard, fonksiyondan istisnayla çıkılsa bile mutex kilidini otomatik bırakır. Üretim kodunda bu RAII yaklaşımı, elle lock ve unlock çağırmaktan daha güvenlidir.

Hangisini ne zaman seçmeli?

Kritik bölüm birkaç atomik işlem kadar kısaysa, çekirdek sayısı yeterliyse ve çakışma düşükse spinlock avantaj sağlayabilir. İşlem bloklayıcı G/Ç yapıyor, bellek ayırıyor veya süresi öngörülemeyen başka kodlar çağırıyorsa mutex daha doğru seçimdir. Spinlock tutulurken uyumak ise performans felaketinin davetiyesidir.

Modern mutex uygulamalarının önce kısa süre dönüp sonra uyuyan adaptif stratejiler kullanabildiğini de unutmayın. Dolayısıyla teorik tahmin tek başına yeterli değildir. Gerçek iş yükünü benchmark ve profiler ile ölçün. En hızlı kilit bazen spinlock, bazen mutex; çoğu zamansa paylaşılan veriyi azaltarak hiç ihtiyaç duymadığınız kilittir.

``

OOM ne zaman devreye girer?

Linux önce boş sayfaları, dosya önbelleklerini ve gerekirse swap alanını kullanır. Bellek ayırma isteği bu yöntemlerle karşılanamazsa OOM koşulu oluşabilir. Bununla birlikte her başarısız tahsis doğrudan küresel bir katliam başlatmaz. Sorun yalnızca belirli bir cgroup’un limitinde yaşanıyorsa cgroup OOM, belirli NUMA düğümleriyle sınırlıysa ilgili bellek politikası kapsamında OOM gerçekleşebilir.

Amaç, en az sistem hasarıyla yeterli belleği geri kazandırmaktır. Basitleştirilmiş düşünce şu şekilde ifade edilebilir:

Bu, kernel kaynak kodunun birebir formülü değildir; karar mantığını anlamaya yarayan bir modeldir. Modern Linux sürümlerinde süreç veya thread grubu tarafından kullanılan RAM ve swap miktarı önemli bir başlangıç noktasıdır. Puan, OOM olayının kapsamındaki kullanılabilir bellek üzerinden değerlendirilir.

Puanları nerede görürüz?

Kernel her süreç için /proc altında iki önemli arayüz sunar:

oom_score ne kadar yüksekse süreç o kadar iştah açıcı bir kurbandır. oom_score_adj ise terazinin kefesine yöneticinin parmağını koyar. Pozitif değer sürecin öldürülme olasılığını artırır; negatif değer koruma sağlar. -1000, süreci OOM seçiminden muaf tutmak için kullanılan özel değerdir.

Aşağıdaki komutlar çalışan kabuğun ayarlarını inceler:

PID=$$
cat /proc/$PID/oom_score
cat /proc/$PID/oom_score_adj

# Süreci daha kolay feda edilebilir yapar.
echo 500 | sudo tee /proc/$PID/oom_score_adj

Son komut yalnızca puan ayarını değiştirir; süreci hemen öldürmez. Ayrıca başka bir kullanıcının sürecini değiştirmek veya negatif değer vermek için uygun yetkiler gerekir.

En çok RAM kullanan kesin ölür mü?

Hayır. Bellek tüketimi güçlü bir etkendir fakat tek etken değildir. Aynı miktarda bellek kullanan iki süreç, farklı oom_score_adj değerleri yüzünden tamamen farklı muamele görebilir. Kernel thread’leri ve OOM için uygun olmayan görevler de seçim dışında kalabilir. Geçmiş kernel sürümlerindeki nice değeri, çalışma süresi veya ayrıcalık gibi ölçütlere dayanan eski açıklamalar ise modern çekirdekler için yanıltıcı olabilir.

OOM Killer kurbanı seçtikten sonra genellikle sürece SIGKILL gönderir. Süreç temizlik kodu çalıştıramaz; kernel onun bellek alanlarının serbest kalmasını bekler. Olayın izi çoğunlukla kernel günlüğündedir:

journalctl -k -g 'Out of memory\|Killed process'
dmesg -T | grep -Ei 'out of memory|killed process'

Pratik savunma stratejisi

Kritik servisleri körlemesine -1000 ile korumak caziptir, fakat herkes dokunulmaz olursa kernel uygun kurban bulamaz. Daha sağlıklı yaklaşım; servisleri cgroup veya systemd bellek limitleriyle ayırmak, geçici worker süreçlerine pozitif ayar vermek ve kritik veritabanlarına ölçülü koruma sağlamaktır. systemd tarafında OOMScoreAdjust=, MemoryHigh= ve MemoryMax= seçenekleri bu politikanın kurulmasına yardımcı olur.

Kısacası OOM Killer kötü niyetli bir cellat değil, belleksiz kalmış sistemin son çare hakemidir. Puanlama mekanizmasını anlamak, kurban listesini tesadüfe bırakmak yerine sistemin hangi yükü önce bırakacağını bilinçli biçimde tasarlamanızı sağlar.

Halkaların temel mantığı

İşlemci, çalışan kodun hangi ayrıcalık seviyesinde olduğunu takip eder. x86 terminolojisinde mevcut seviye CPL (Current Privilege Level) olarak adlandırılır. Kaynakların ve kod bölümlerinin erişim seviyesi ise DPL (Descriptor Privilege Level) gibi alanlarla belirtilir.

Basitleştirilmiş erişim düşüncesi şu eşitsizlikle anlatılabilir:

Burada küçük sayı daha yüksek yetkiyi temsil eder. Dolayısıyla Ring 0 kodu pek çok ayrıcalıklı kaynağa ulaşabilirken Ring 3 kodu aynı işlemi yapmaya çalıştığında işlemci bir koruma hatası üretir.

Linux, Windows ve çoğu genel amaçlı işletim sistemi pratikte iki seviyeli bir model kullanır: çekirdek Ring 0’da, uygulamalar Ring 3’te çalışır. Ring 1 ve Ring 2 donanımda bulunsa da taşınabilirlik ve tasarım sadeliği nedeniyle çoğunlukla boş bırakılır.

Duvar işlemci seviyesinde nasıl kurulur?

Duvarın ilk tuğlası ayrıcalıklı komutlardır. Kesme sistemini kapatan cli, kontrol yazmaçlarını değiştiren talimatlar veya sayfa tablolarını yöneten işlemler Ring 3’te yürütülemez. Bir uygulama bunları denerse CPU işlemi reddeder ve çekirdeğe bir istisna bildirir.

İkinci tuğla bellek korumasıdır. Sanal bellekteki her sayfa için sayfa tablosu girdileri bulunur. x86 mimarisindeki U/S biti, sayfanın kullanıcı modundan erişilebilir olup olmadığını belirtir:

Buna yazılabilirlik ve çalıştırılabilirlik bitleri de eklenir. Böylece bir süreç başka bir sürecin ya da çekirdeğin belleğine yalnızca adresini tahmin ederek ulaşamaz.

Uygulamalar hizmeti nasıl ister?

Ring 3 tamamen çaresiz değildir; çekirdekten kontrollü biçimde yardım ister. Bunun kapısı sistem çağrısıdır. x86-64 sistemlerinde syscall komutu işlemciyi önceden belirlenmiş çekirdek giriş noktasına taşır, ayrıcalık seviyesini değiştirir ve kullanıcı bağlamının geri yüklenebilmesi için gerekli bilgileri saklar.

#include <unistd.h>

int main(void) {
    const char mesaj[] = "Merhaba, cekirdek!\n";
    write(1, mesaj, sizeof(mesaj) - 1);
    return 0;
}

Buradaki write, ekrana doğrudan erişmez. Standart kütüphane uygun sistem çağrısını başlatır; çekirdek dosya tanımlayıcısını ve kullanıcı belleğindeki adresi doğrular. İstek güvenliyse terminal sürücüsüne kadar uzanan işi çekirdek gerçekleştirir.

Geçişin maliyeti kabaca şöyle düşünülebilir:

Bu nedenle her küçük işlem için sistem çağrısı yapmak yerine tamponlama kullanılır. Örneğin yüzlerce karakter tek tek değil, bir blok hâlinde yazılabilir.

Kesintiler, hatalar ve kontrollü dönüş

Donanım kesintileri ve sayfa hataları da kontrolü çekirdeğe aktarabilir. İşlemci, IDT içindeki hedef kapının yetki kurallarını denetler; rastgele bir adrese sıçramaz. Çekirdek olayı işledikten sonra özel dönüş talimatlarıyla Ring 3 bağlamını geri yükler.

Sonuç olarak kullanıcı modu ile çekirdek modu arasındaki duvar basit bir programlama geleneği değildir. Ayrıcalıklı komutlar, sayfa tabloları, kesme kapıları ve sistem çağrısı mekanizması birlikte çalışır. Uygulama kontrolden çıksa bile işlemci ona nazikçe ama kesin biçimde şunu söyler: Donanıma dokunmak istiyorsan önce çekirdekten izin al.

``

Sürü zekâsı nedir?

Sürü zekâsı, basit kuralları izleyen çok sayıda bireyin etkileşiminden ortaya çıkan kolektif problem çözme yeteneğidir. Buradaki temel fikir, tek bir bireyin kusursuz olmasına gerek olmadığıdır. Bireyler kendi deneyimlerini grubun deneyimiyle birleştirdiğinde etkili bir arama mekanizması oluşur.

PSO, 1995 yılında James Kennedy ve Russell Eberhart tarafından geliştirilmiştir. Algoritmada her olası çözüm bir parçacık, tüm parçacıklar ise bir sürü olarak temsil edilir. Parçacıklar çözüm uzayında dolaşarak amaç fonksiyonunun en iyi değerini arar.

PSO nasıl çalışır?

Her parçacığın bir konumu $x_i$ ve hızı $v_i$ bulunur. Ayrıca parçacık, şimdiye kadar keşfettiği en iyi konumu $p_i$ olarak hatırlar. Sürünün bulduğu en iyi konum ise $g$ ile gösterilir.

Hız güncelleme denklemi şöyledir:

Yeni konum da şu şekilde hesaplanır:

Burada $w$ eylemsizlik katsayısıdır ve parçacığın önceki yönünü ne kadar koruyacağını belirler. $c_1$ bilişsel katsayıdır; parçacığın kendi deneyimine bağlılığını temsil eder. $c_2$ sosyal katsayıdır ve sürünün keşfine verilen önemi kontrol eder. $r_1$ ile $r_2$, $[0,1]$ aralığında rastgele sayılardır. Bu rastlantısallık, bütün parçacıkların erkenden aynı noktaya yığılmasını önlemeye yardımcı olur.

Python ile basit bir uygulama

Aşağıdaki örnek, $f(x)=x^2$ fonksiyonunun minimumunu arar. Teorik minimum $x=0$ noktasındadır.

import random

parcacik_sayisi = 20
konumlar = [random.uniform(-10, 10) for _ in range(parcacik_sayisi)]
hizlar = [random.uniform(-1, 1) for _ in range(parcacik_sayisi)]
kisisel_en_iyi = konumlar.copy()

def uygunluk(x):
    return x ** 2

kuresel_en_iyi = min(kisisel_en_iyi, key=uygunluk)

for _ in range(100):
    for i in range(parcacik_sayisi):
        r1, r2 = random.random(), random.random()
        hizlar[i] = (
            0.7 * hizlar[i]
            + 1.5 * r1 * (kisisel_en_iyi[i] - konumlar[i])
            + 1.5 * r2 * (kuresel_en_iyi - konumlar[i])
        )
        konumlar[i] += hizlar[i]

        if uygunluk(konumlar[i]) < uygunluk(kisisel_en_iyi[i]):
            kisisel_en_iyi[i] = konumlar[i]

    kuresel_en_iyi = min(kisisel_en_iyi, key=uygunluk)

print("Bulunan minimum noktası:", kuresel_en_iyi)

Kod, parçacıkları rastgele başlatır; ardından hız ve konumlarını 100 tur boyunca günceller. Her turda bireysel ve küresel rekorlar yenilenir. Sonuç genellikle sıfıra oldukça yakın çıkar.

Yapay zekâdaki kullanım alanları

PSO; sinir ağlarının ağırlıklarını ayarlamak, özellik seçmek, hiperparametre optimizasyonu yapmak, robot rotaları planlamak ve enerji sistemlerini düzenlemek için kullanılabilir. Türev bilgisi istememesi, karmaşık ve doğrusal olmayan problemlerde önemli bir avantajdır. Buna karşılık doğru katsayılar seçilmezse yerel optimuma erken yakınsayabilir ve yüksek boyutlarda maliyetli hâle gelebilir.

Kısacası PSO, “en iyi çözümü tek başına bul” yaklaşımı yerine “deneyimini paylaş ve birlikte ara” der. Bazen karmaşık bir problemi çözmek için gereken şey daha güçlü bir birey değil, daha iyi iletişim kuran bir sürüdür.