Linux kernel 7.2 yenilikleri ve VPS performansı

Linux kernel 7.2 sürümündeki yenilikler

Linux kernel 7.2, 16 Ağustos 2026 tarihinde yayınlanmıştır. Dikkat etmeniz gereken en önemli değişiklik, yeni CONFIG_SCHED_CACHE seçeneği ile gelen önbellek duyarlı (cache aware) zamanlamadır. Zamanlayıcı artık bir sürecin iş parçacıklarını, aynı son seviye önbelleği (LLC) paylaşan CPU'larda tutmaya çalışmaktadır. Bu sürümde iş yükünüzün CPU üzerindeki yerleşimini değiştiren başka bir yenilik bulunmamaktadır.

7.2 sürümünün geri kalanı özetle şöyledir: ext4 hızlı commit yolunun yeniden düzenlenmesi, MGLRU (çok nesilli en az kullanılan bellek geri kazanım kodu) iyileştirmeleri, satır içi blok aygıt şifrelemesi için yeni bir dm-inlinecrypt aygıt eşleyici hedefi ve çekirdek kaynak kodundan son strncpy() çağrısının kaldırılması.

Manşet özelliğinin sizin için bir anlam ifade edip etmeyeceğine karar veren tek bir gerçek vardır, bu yüzden önce buna değinilmelidir. Önbellek duyarlı yük dengeleme, yalnızca bir NUMA (düzensiz bellek erişimi) düğümü birden fazla LLC içerdiğinde devreye girer. Bir VPS konuğu genellikle bu yerleşimi görmez, bu nedenle çoğu konuk sistemde kod derlenmiş olsa bile asla çalışmaz. Bunun kontrolü, aşağıdaki "Bir VPS konuğu bunlardan herhangi birini görüyor mu" bölümünde yer alan iki komutla yapılabilir.

Bu sayfadaki her teknik iddia, 18 Ağustos 2026 tarihinde incelenen 7.2 değişiklik günlüğünden ve önbellek duyarlı zamanlama yama serisinden alınmıştır. Kaynaklar, kendi çekirdeğinizle karşılaştırma yapabilmeniz için son kısımda listelenmiştir.

Zamanlayıcının önbellekler hakkında bilgi sahibi olması neden gereklidir

Modern bir sunucu soketi tek bir son seviye önbelleğe (LLC) sahip değildir. Bir AMD EPYC paketi, her biri kendi L3 önbelleğine sahip birkaç çekirdek kümesinden (core complex) oluşturulmuştur. Güncel Intel Xeon işlemciler de bir soketi birden fazla önbellek etki alanına böler. Bu nedenle tek bir NUMA düğümü dört, sekiz veya daha fazla ayrı LLC barındırabilir ve aynı programın iki iş parçacığı (thread) farklı önbelleklerde çalışabilir.

Bu yerleşim zaman kaybına neden olur. İki iş parçacığı aynı bellek sayfasını farklı LLC'lerden paylaştığında, her önbellek ilgili satırın kendi kopyasını tutar. Bir taraftaki yazma işlemi diğer taraftaki kopyayı geçersiz kılar; bu nedenle bir sonraki okuma işlemi ara bağlantı (interconnect) üzerinden geçmek veya ana belleğe gitmek zorunda kalır. Buna önbellek sıçraması (cache bouncing) denir. Bu durum, CPU boşta kalma süresi olarak değil, beklemede harcanan döngüler olarak ortaya çıkar; bu yüzden yük ortalamasını izlerken gözden kaçırılması kolaydır.

7.2 sürümünden önce yük dengeleyici, görevleri yük, kullanım oranı ve boşta olan CPU'lara göre yerleştiriyordu. "Bu iki görev aynı belleği okuyor" bilgisini sağlayan bir girdi yoktu. 7.2 sürümü, hesaplama maliyeti olmayan bir yaklaşımla bu eksikliği giderir: Bir sürecin iş parçacıkları aynı adres alanını paylaştığından, veriyi de paylaşmaları muhtemel kabul edilir.

Çekirdeğin tercih edilen bir LLC'yi nasıl seçtiği

İzleme süreci, tek bir adres alanını temsil eden çekirdek yapısı mm_struct içinde, sürecin kendisine bağlı olarak yürütülür. Çekirdek, sürecin iş parçacıklarının nerede çalıştığını periyodik olarak örnekler ve LLC başına, sürecin ne kadarının her birinde bulunduğunu sayar. En fazla veriyi barındıran LLC, tüm süreç için tercih edilen LLC haline gelir ve sonraki kararların okuduğu tek değer bu sayıdır.

Daha sonra iki yol bunu kullanır. Uyandırma sırasında zamanlayıcı, düğümdeki herhangi bir boş CPU'yu almak yerine CPU seçimini sürecin tercih ettiği LLC'ye doğru yönlendirir. Yük dengeleme sırasında, görevlerin zamanlayıcı grupları arasında taşınması gerektiğinde, halihazırda hedef LLC'yi tercih eden görevleri taşımayı yeğler ve bir görevi tercih ettiği LLC'den uzaklaştırmaktan kaçınır.

Koruma mekanizmaları, özelliğin kendisi kadar önemlidir; çünkü yoğun bir sürecin her iş parçacığını tek bir önbellek etki alanına sıkıştırmak, soketin geri kalanı boşta dururken o etki alanının aşırı yüklenmesine neden olabilir. Ayarlanabilir parametreler, çekirdeğin hata ayıklama dosya sistemi olan debugfs içinde, /sys/kernel/debug/sched/ altında bulunur:

• llc_aggr_tolerance, 0 ile 100 arasında bir değer olup çekirdeğin ne kadar sıkı kümeleme yapacağını belirler. 0, önbellek duyarlı zamanlamayı çalışma zamanında kapatır. 1 dikkatli bir ayardır: RSS'si (yerleşik küme boyutu, yani yerleşik belleği) LLC'den daha büyük olan veya LLC'nin sahip olduğu çekirdek sayısından daha fazla iş parçacığı çalıştıran bir süreç olduğu yerde bırakılır. 100 ise boyut veya iş parçacığı sayısı ne olursa olsun kümeleme yapar.
• llc_overload_pct, varsayılan değeri 50, tercih edilen LLC'nin meşgul sayılması için gereken ortalama kullanım eşiğidir.
• llc_imb_pct, varsayılan değeri 20, tercih edilen LLC bu aşırı yüklenme noktasını geçtikten sonra kümeleyici bir taşımanın yaratabileceği dengesizliği sınırlar.
• llc_epoch_period, varsayılan değeri 10 ms, doluluk oranının ne sıklıkla toplandığını belirtir.
• llc_epoch_affinity_timeout, varsayılan değeri 50 ms, etkin olmayan bir sürecin, çekirdek tercihi bırakmadan önce tercihini ne kadar süre koruyacağını belirler.

Herhangi birini değiştirmeden önce kendi değerlerinizi okuyun, çünkü bir dağıtım farklı varsayılan ayarlarla gelebilir: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Hangi iş yükleri makul ölçüde kazanç sağlar, hangileri sağlamaz

Aşağıdaki rakamlar, sunucu sınıfı donanımlar üzerinde ölçülmüş ve bazıları tolerans ayarı agresif seviyeye getirilmiş şekilde yama serisiyle birlikte yayınlanan verilerdir. Bunları çıplak donanım üzerindeki en iyi senaryo olarak değerlendirin, kendi sisteminiz için bir garanti olarak görmeyin.

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

Tek bir grup ile Hackbench 30.57% oranında iyileşme göstermiş, AMD Genoa üzerinde çalıştırılan ChaCha20 iş hacmi ise 44% oranında artmıştır. Toplam 3 sonuç, test edenin uçtan uca kontrol ettiği çoklu LLC sunucu donanımı üzerinde alınmıştır.

Kazanç sağlayan bir iş yükünün yapısı şu şekildedir:

• Tek bir süreç içinde birden fazla iş parçacığı (thread) bulunması; böylece gruplanacak bir yapı mevcuttur.
• Bu iş parçacıkları arasında gerçek bir veri paylaşımı olması; böylece önbellek satırı (cache line) sıçraması ödenen bir maliyettir.
• Çalışma kümesinin bir LLC içine sığması; çünkü önbellekten daha büyük bir süreç, taşınarak önbellek yerelliği kazanamaz.
• Makinede boş kapasite olması; böylece zamanlayıcının bir sonraki iş parçacığını nereye yerleştireceği konusunda gerçek bir seçeneği vardır.

Kazanç sağlanamayan durumlar ise şunlardır:

• Tam kapasitede çalışan bir makine. Her CPU meşguldür, bu nedenle yerleşim zorunludur ve bildirilen kazançlar kaybolur.
• Tek iş parçacıklı süreçler ve veri paylaşmayan bağımsız süreç havuzları.
• LLC'den çok daha büyük bir çalışma kümesi; bu durum dikkatli llc_aggr_tolerance ayarı tarafından bilinçli olarak atlanır.
• Tek bir LLC bildiren bir düğüm; bu durumda özellik hiçbir şekilde devreye girmez.

İşin bir de maliyet tarafı vardır ve seri bu konuda şeffaftır. Doluluk oranını toplamak, görevin bağlamı içinde yapılan bir işlemdir ve bazı çalışmalarda, bu işlemin görevin kullanıcı alanına dönüşünü geciktirmesi nedeniyle istek gecikmesinin kötüleştiği gözlemlenmiştir. Toplama işlemi, ortalama iş hacmi iyileşse bile gecikme değişkenliğini artırabilir. Eğer ortalamadan ziyade uç değerlerle (tail latency) ilgileniyorsanız, kendi uç değerlerinizi ölçün.

Bir VPS konuğu bunları görür mü

Cevabı iki olgu belirler.

Birincisi, özellik topolojiye bağlıdır. Önbellek duyarlı yük dengeleme, yalnızca bir NUMA düğümü içinde birden fazla LLC mevcut olduğunda etkinleştirilir ve çekirdek bunu topoloji kurulumu sırasında kaydeder. Bir düğüm tek bir LLC bildirdiğinde, ayarlanabilir parametreler nasıl yapılandırılırsa yapılandırılsın, önbellek duyarlı yol etkin kalmaz.

İkincisi, konuğunuzun okuduğu önbellek topolojisi, ana makinenin (host) topolojisi değildir. Bu, hipervizörün CPU modelinin sunduğu topolojidir. Varsayılan bir KVM (kernel based virtual machine) konuğuna genellikle ana makinenin gerçek L3 düzeni verilmez; bu nedenle konuk, basitleştirilmiş bir resim üzerinden işlem yapar.

Kendi konuğunuzun ne gördüğünü kontrol edin:

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3, çoğu x86 CPU üzerindeki L3 önbelleğidir. Her vCPU'yu listeleyen tek bir satır, konuğun tek bir LLC gördüğü anlamına gelir; bu nedenle özelliğin düzenleyeceği bir şey yoktur. No such file or directory, konuğa hiçbir L3 önbelleğinin sunulmadığı anlamına gelir ve konuk, bu durumda daha alt bir önbellek seviyesini son seviye olarak kabul eder; bu sınırlar silikonun gerçek sınırları değil, hipervizör tarafından oluşturulmuş sınırlardır.

Bir de her kiracı için dürüst bir uyarı olan çift zamanlama (double scheduling) konusu vardır. Konuk çekirdeğiniz iş parçacıklarını vCPU'lara yerleştirir. Ana makine çekirdeği ise bu vCPU iş parçacıklarını fiziksel çekirdeklere yerleştirir. Dört iş parçacığını dikkatlice vCPU 0 ile 3 arasına gruplayan bir konuk, dört ana makine iş parçacığı hakkında bir tercih belirtmiş olur; ancak ana makine bunları farklı fiziksel önbellek alanlarına yerleştirmekte ve daha sonra taşımakta özgürdür. Konuğun kararı yanlış değildir, sadece nihai karar değildir. Bu, gürültülü bir komşunun vCPU'larınızda bıraktığı steal time değerini üreten katman sınırı ile aynıdır.

Peki bu özellik bir VPS kiracısına nerede ulaşır? İki yerde. Topolojinin sentetik değil gerçek olduğu planlarda, örneğin ayrılmış çekirdekler veya passthrough düzenine sahip daha büyük örneklerde, konuk zamanlayıcı mevcut olan donanım hakkında bir karar verir. Ayrıca, sağlayıcının kendi ana makine çekirdeğinde, vCPU iş parçacıklarınızın önbellek duyarlı yerleşimi sağlayıcının elde edeceği bir kazançtır, sizin değil. Önbellek düzeni mimariye göre de değişir; bu, bir Arm VPS ile bir x86 VPS karşılaştırması yaparken dikkate alınması gereken bir başka değişkendir.

Bir konuk içinde önbellek davranışını ölçmek, çıplak donanım üzerinde ölçmekten daha zordur. perf stat -e cache-misses, hipervizör PMU'yu (performans izleme birimi) konuklara açmadığı için genellikle <not supported> rapor eder. Bunun yerine kendi uygulamanızın iş hacmini ve gecikme süresini ölçün ve iki çalışma arasındaki anahtar olarak debugfs düğmesini kullanın.

Çekirdeğinizin CONFIG_SCHED_CACHE içerip içermediğini kontrol edin

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

CONFIG_SCHED_CACHE=y, çekirdeğinizin bu seçenekle derlendiği anlamına gelir. # CONFIG_SCHED_CACHE is not set şeklinde bir satır, seçeneğin ilgili sürümde mevcut olduğunu ancak dağıtımınız tarafından devre dışı bırakıldığını gösterir. Hiç çıktı alınamaması genellikle çekirdeğin bu seçenekten daha eski olduğu anlamına gelir; uname -r bunu doğrulayacaktır. Bazı minimal bulut imajları /boot/config-* dosyasını içermez; bu durumda, yalnızca çekirdek CONFIG_IKCONFIG_PROC ile derlenmişse çalışan zcat /proc/config.gz komutunu kullanabilirsiniz.

ls satırı, özellik derlendiğinde llc_* ayarlanabilir değerlerini yazdırır. CONFIG_SCHED_CACHE=y durumundayken hiçbir çıktı alınamıyorsa, önce sudo mount -t debugfs none /sys/kernel/debug ile debugfs dosya sistemini bağlayın.

İş yükünüzü özelliğin açık ve kapalı olduğu durumlar için karşılaştırmak amacıyla, geri yüklemeniz gerekeceğinden mevcut değeri öncelikle kaydedin:

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

Kıyaslama (benchmark) testinizi çalıştırın, not ettiğiniz değeri tekrar yazın ve testi yeniden gerçekleştirin. Debugfs üzerinden yapılan yazma işlemleri yeniden başlatma sonrasında kalıcı olmaz; test aşamasında istenen durum da budur.

Bir dağıtım çekirdeği 7.2 sürümünü ne zaman destekleyecek

VPS'nizin açılışında kullanılan çekirdek, mainline çekirdeği değildir. uname -r içindeki sürüm dağıtımınız tarafından sağlanır ve her dağıtımın mainline sürümünden sunucunuza ulaşan kendine özgü bir süreci vardır.

Fedora, kararlı sürümlerini destek ömürleri boyunca yeni mainline çekirdeklerine günceller; bu nedenle sudo dnf upgrade --refresh komutu ve ardından bir yeniden başlatma işlemi genellikle yeterlidir. Fedora, bir kullanıcının yeni bir çekirdeği deneyebileceği ilk yer olma eğilimindedir. Bu güncelleme sıklığı, Fedora Server on a VPS kullanmayı seçtiğinizde kabul ettiğiniz bir durumdur.

Ubuntu, her altı aylık sürümle birlikte yeni bir çekirdek sunar ve ardından bunu HWE (hardware enablement) yığını aracılığıyla önceki uzun süreli destek (LTS) sürümüne taşır. Ağustos 2026 itibarıyla, Ubuntu 24.04 LTS hala GA çekirdeği olarak Nisan 2024 tarihli 6.8 sürümünü kurmaktadır; HWE yığını ise Ağustos 2025'te 6.14'e, Şubat 2026'da ise 6.17'ye geçmiştir. Gerçekçi zaman çizelgesi budur: Ağustos 2026 tarihli bir mainline sürümü, bir LTS HWE yığınına yaklaşık bir yıl sonra ulaşır.

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

Debian stable, sürüm ömrü boyunca tek bir çekirdek sürümünü korur ve daha yeni sürümleri, paket bazında dahil olabileceğiniz backports aracılığıyla sunar:

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

Bu işlemlerden herhangi birinin ardından sistemi yeniden başlatın ve uname -r ile yukarıdaki grep komutlarını kullanarak doğrulamayı yapın. Yeni bir çekirdek canlı olarak yüklenemez: live kernel patching on a VPS yöntemi, çalışan çekirdekteki bireysel fonksiyonların kodunu değiştirir; ancak yapı düzenlerini değiştiremez veya debugfs dosyaları ekleyemez. Cache aware scheduling her ikisini de yapar, çünkü mm_struct yapısına alanlar ekler; bu nedenle yalnızca yeni bir çekirdeği başlatarak kullanılabilir hale gelir.

İki pratik takip adımı bulunmaktadır. Yeni çekirdek yükünüzü bir süre sorunsuz taşıyana kadar eski çekirdeği açılabilir durumda tutun; pinning which kernel boots on a VPS konusu bunun içindir. Ayrıca /boot dosyasını izleyin; küçük bir VPS önyükleme bölümü birkaç çekirdek yükseltmesinden sonra dolar, bu durum cleaning up old kernels on Ubuntu içinde ele alınmıştır.

Sahiplik konusunda son bir gerçekçi not: KVM tabanlı bir VPS üzerinde misafir çekirdeği size aittir; onu siz seçer, siz başlatır ve gerekirse geri alırsınız. Ana makine (host) çekirdeği ise sağlayıcınıza aittir ve misafir sisteminizdeki hiçbir ayar, hipervizörün hangi zamanlayıcıyı (scheduler) çalıştırdığını değiştiremez. Bu nedenle, zamanlayıcı yerleşimi hakkındaki bir sürüm notu, bir kullanıcı için hikayenin yalnızca yarısıdır; kontrol edebileceğiniz kısım ise misafir tarafıdır.

Bu sayfa için kullanılan kaynaklar

• 16 Ağustos 2026 sürüm tarihi ve zamanlayıcı dışı değişiklikler için kernelnewbies.org adresindeki 7.2 sürüm notları özeti.
• debugfs ayarlanabilir parametreleri, süreç bazlı tercih mekanizması ve raporlanan performans testi verileri için lwn.net/Articles/1041668 ve lwn.net/Articles/1058288 adreslerinde yer alan, önbellek duyarlı zamanlama serisine dair LWN incelemesi.
• Önbellek duyarlı yük dengelemenin bir NUMA düğümünde birden fazla LLC gerektirdiği kuralı için "sched/cache: Introduce sched_cache_present" adlı, özelliği topolojiye göre kısıtlayan yama.

Bir önceki sürüm için bkz: Linux kernel 7.1 sürümündeki değişiklikler. Sürüm numaralarının nasıl bu noktaya geldiği için bkz: Linux kernel geçmişi zaman çizelgesi.

FAQ

Linux 7.2 sürümündeki önbellek duyarlı zamanlama (cache aware scheduling) bir VPS'i hızlandırır mı?

Genellikle tek başına hızlandırmaz. Bu özellik yalnızca bir NUMA düğümü birden fazla son seviye önbellek (last level cache) bildirdiğinde etkinleşir; tipik bir KVM konuğu bu düzeni görmediği için kod asla devreye girmez. Devreye girdiği durumlarda bile konuk sistem iki kez zamanlanır: çekirdeğiniz bir vCPU seçer, ancak ana makine (host) çekirdeği bu vCPU iş parçacığının hangi fiziksel çekirdek üzerinde çalışacağına karar verir. Bu nedenle, konuk tarafındaki bir önbellek kararı ana makine tarafından geçersiz kılınabilir. Konuğunuzda cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u komutunu çalıştırın. Her vCPU'yu kapsayan tek bir satır, özelliğin düzenleyebileceği bir şey olmadığını gösterir.

Çekirdeğimin CONFIG_SCHED_CACHE özelliğine sahip olup olmadığını nasıl kontrol ederim?

grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) komutunu çalıştırın. CONFIG_SCHED_CACHE=y çıktısı özelliğin derlendiği, # CONFIG_SCHED_CACHE is not set çıktısı dağıtımınızın bunu devre dışı bıraktığı, çıktı alınamaması ise çekirdeğin bu seçenekten daha eski olduğu anlamına gelir. Eğer imajda /boot/config-* dosyası yoksa, yalnızca CONFIG_IKCONFIG_PROC ile derlenen çekirdeklerde bulunan zcat /proc/config.gz dosyasını deneyin. Özellik mevcut olduğunda llc_* ayarlanabilirlerini listeleyen sudo ls /sys/kernel/debug/sched/ | grep -i llc komutu ile çalışma zamanında doğrulama yapabilirsiniz.

Yeniden başlatmadan önbellek duyarlı zamanlamayı nasıl kapatırım?

Tolerans düğmesine 0 değerini yazın: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Bu, özelliği çalışma zamanında devre dışı bırakır ve kıyaslama (benchmark) için temiz bir A/B anahtarı sağlar. Varsayılan değerler derlemeler arasında değiştiği için önce sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance ile mevcut değeri okuyun ve işlem sonrasında tekrar yazın. debugfs içine yazılan hiçbir şey yeniden başlatma sonrasında kalıcı olmaz. Eğer cat komutu No such file or directory çıktısını veriyorsa, çekirdeğinizde bu özellik derlenmemiştir ve kapatılacak bir şey yoktur.

Ubuntu veya Debian ne zaman 7.2 tabanlı bir çekirdek yayınlayacak?

Fedora, kararlı sürümleri yeni ana hat (mainline) çekirdeklerine göre günceller; bu nedenle özellik oraya normal bir dnf upgrade ve yeniden başlatma ile ilk önce gelir. Ubuntu, her altı aylık sürümle yeni çekirdekler sunar ve bunları HWE yığını aracılığıyla önceki LTS sürümlerine taşır. Tarihsel boşluk yaklaşık bir yıldır: Ağustos 2026 itibarıyla 24.04 LTS HWE yığını Şubat 2026 tarihli 6.17 sürümündeyken, GA çekirdeği hala 6.8 sürümündedir. Debian stable, sürüm için tek bir çekirdeği korur ve daha yenilerini trixie-backports aracılığıyla sunar; bunları apt install -t trixie-backports linux-image-amd64 ile paket bazında yüklersiniz.