Linux kernel 7.2 में नया क्या है और VPS के लिए उपयोगिता

Linux kernel 7.2 में नया क्या है

Linux kernel 7.2 को 16 August 2026 को release किया गया था। इसमें ध्यान देने योग्य बदलाव cache aware scheduling है, जिसे नए CONFIG_SCHED_CACHE option के पीछे बनाया गया है। scheduler अब एक process के threads को उन CPUs पर रखने का प्रयास करता है जो एक ही last level cache (LLC) साझा करते हैं। इस release में आपके workload को CPU पर रखने के तरीके में कोई अन्य बदलाव नहीं किया गया है।

7.2 के बाकी बदलाव संक्षेप में: ext4 fast commit path का पुनर्गठन, MGLRU (multi-generational least recently used memory reclaim code) में सुधार, inline block device encryption के लिए एक नया dm-inlinecrypt device mapper target, और kernel source से अंतिम strncpy() call को हटाना।

एक तथ्य यह तय करता है कि क्या मुख्य feature आपके लिए उपयोगी है, इसलिए इसे पहले बताया गया है। Cache aware load balancing केवल तब सक्रिय होता है जब एक NUMA (non-uniform memory access) node में एक से अधिक LLC हों। एक VPS guest को आमतौर पर वह layout नहीं दिखाया जाता है, इसलिए अधिकांश guests पर यह code compile तो होता है लेकिन कभी सक्रिय नहीं होता। इसकी जाँच करने के लिए नीचे "क्या एक VPS guest को इनमें से कुछ दिखाई देता है" अनुभाग में दो commands दी गई हैं।

इस पृष्ठ पर प्रत्येक तकनीकी दावा 7.2 changelog और cache aware scheduling patch series से लिया गया है, जिसे 18 August 2026 को पढ़ा गया था। स्रोत अंत के पास सूचीबद्ध हैं ताकि आप उनकी तुलना अपने स्वयं के kernel से कर सकें।

शेड्यूलर को कैश (caches) के बारे में जानकारी की आवश्यकता क्यों थी

आधुनिक सर्वर सॉकेट में केवल एक अंतिम स्तर का कैश (last level cache) नहीं होता है। एक AMD EPYC पैकेज कई कोर कॉम्प्लेक्स से बना होता है, और प्रत्येक कॉम्प्लेक्स का अपना L3 कैश होता है। हाल के Intel Xeon पार्ट्स भी एक सॉकेट को एक से अधिक कैश डोमेन में विभाजित करते हैं। इसलिए, एक एकल NUMA नोड में चार, आठ या उससे अधिक अलग-अलग LLC हो सकते हैं, और एक ही प्रोग्राम के दो थ्रेड अलग-अलग LLC में समाप्त हो सकते हैं।

यह प्लेसमेंट समय की बर्बादी करता है। जब दो थ्रेड अलग-अलग LLC से एक पेज साझा करते हैं, तो प्रत्येक कैश लाइन की अपनी कॉपी रखता है। एक तरफ किया गया राइट (write) दूसरी तरफ की कॉपी को अमान्य (invalidate) कर देता है, इसलिए अगले रीड (read) को इंटरकनेक्ट को पार करना पड़ता है या मुख्य मेमोरी तक जाना पड़ता है। इसे कैश बाउंसिंग (cache bouncing) कहते हैं। यह प्रतीक्षा में व्यतीत चक्रों (cycles) के रूप में दिखाई देता है, न कि CPU के खाली समय के रूप में, यही कारण है कि लोड एवरेज (load average) देखते समय इसे अनदेखा करना आसान होता है।

7.2 से पहले, लोड बैलेंसर लोड, उपयोग और खाली CPU का उपयोग करके कार्यों को व्यवस्थित करता था। इसमें ऐसा कोई इनपुट नहीं था जो यह बताए कि "ये दो कार्य एक ही मेमोरी को पढ़ते हैं"। 7.2 ने इसे जोड़ा है, एक ऐसे अनुमान का उपयोग करके जिसकी गणना की लागत शून्य है: एक प्रोसेस के थ्रेड एक ही एड्रेस स्पेस साझा करते हैं, इसलिए उन्हें ऐसा माना जाता है कि वे डेटा साझा करेंगे।

कर्नेल पसंदीदा LLC का चयन कैसे करता है

यह ट्रैकिंग प्रोसेस के साथ जुड़ी होती है, जो mm_struct में स्थित है, यह कर्नेल संरचना एक एड्रेस स्पेस का प्रतिनिधित्व करती है। कर्नेल समय-समय पर यह नमूना लेता है कि उस प्रोसेस के थ्रेड्स कहाँ चल रहे हैं और प्रति LLC यह गणना करता है कि प्रोसेस का कितना हिस्सा प्रत्येक में स्थित है। जिस LLC में सबसे अधिक हिस्सा होता है, वह पूरी प्रोसेस के लिए पसंदीदा LLC बन जाता है, और यही वह एकल संख्या है जिसे बाद के निर्णय पढ़ते हैं।

इसके बाद दो रास्ते इसका उपयोग करते हैं। वेकअप पर, शेड्यूलर नोड में किसी भी idle CPU को लेने के बजाय प्रोसेस के पसंदीदा LLC की ओर अपने CPU चयन को प्राथमिकता देता है। लोड बैलेंसिंग के दौरान, जब टास्क को शेड्यूलर ग्रुप्स के बीच ले जाना होता है, तो यह उन टास्क को स्थानांतरित करना पसंद करता है जो पहले से ही गंतव्य LLC को प्राथमिकता देते हैं, और यह किसी टास्क को उसके पसंदीदा LLC से दूर ले जाने से बचता है।

गार्डरेल्स (guardrails) उतनी ही महत्वपूर्ण हैं जितना कि यह फीचर, क्योंकि एक व्यस्त प्रोसेस के हर थ्रेड को एक कैश डोमेन में पैक करने से वह डोमेन ओवरलोड हो सकता है जबकि सॉकेट का बाकी हिस्सा idle रह जाता है। ट्यूनेबल्स (tunables) debugfs में स्थित होते हैं, जो कर्नेल का डिबग फाइलसिस्टम है, /sys/kernel/debug/sched/ के अंतर्गत:

• llc_aggr_tolerance, 0 से 100 तक का मान, यह निर्धारित करता है कि कर्नेल कितनी सख्ती से एग्रीगेट (aggregate) करता है। 0 रनटाइम पर कैश-अवेयर शेड्यूलिंग को बंद कर देता है। 1 एक सावधानीपूर्वक सेटिंग है: एक प्रोसेस जिसका RSS (रेसिडेंट सेट साइज, उसकी रेसिडेंट मेमोरी) LLC से बड़ा है, या जो LLC में मौजूद कोर की संख्या से अधिक थ्रेड्स चलाती है, उसे वहीं छोड़ दिया जाता है। 100 आकार या थ्रेड काउंट की परवाह किए बिना एग्रीगेट करता है।
• llc_overload_pct, डिफ़ॉल्ट 50, वह औसत उपयोग है जिसके ऊपर पसंदीदा LLC को व्यस्त माना जाता है।
• llc_imb_pct, डिफ़ॉल्ट 20, उस असंतुलन को सीमित करता है जो एक एग्रीगेटिंग माइग्रेशन तब पैदा कर सकता है जब पसंदीदा LLC उस ओवरलोड बिंदु से आगे निकल जाता है।
• llc_epoch_period, डिफ़ॉल्ट 10 ms, वह अंतराल है जिस पर ऑक्यूपेंसी (occupancy) एकत्र की जाती है।
• llc_epoch_affinity_timeout, डिफ़ॉल्ट 50 ms, वह समय है जब तक एक निष्क्रिय प्रोसेस अपनी प्राथमिकता बनाए रखती है, इससे पहले कि कर्नेल उसे हटा दे।

किसी भी मान को बदलने से पहले अपने स्वयं के मान पढ़ें, क्योंकि कोई डिस्ट्रिब्यूशन अलग डिफ़ॉल्ट मानों के साथ आ सकता है: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance।

किन workloads को लाभ होता है और किनको नहीं

नीचे दिए गए आंकड़े patch series के साथ प्रकाशित किए गए हैं। इन्हें server class hardware पर मापा गया है, और इनमें से कुछ को aggressive setting पर test किया गया है। इन्हें bare metal पर सर्वोत्तम स्थिति के रूप में देखें, न कि अपने सिस्टम के लिए किसी गारंटी के रूप में।

[
  {
    "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
  }
]

Hackbench एक single group के साथ 30.57% तक बेहतर हुआ, और AMD Genoa पर ChaCha20 throughput 44% तक बेहतर हुआ। सभी 3 परिणाम multi-LLC server hardware पर लिए गए थे, जिसे tester ने पूरी तरह नियंत्रित किया था।

लाभ प्राप्त करने वाले workload का स्वरूप इस प्रकार होता है:

• एक ही process में एक से अधिक thread, ताकि grouping के लिए कुछ मौजूद हो।
• उन threads के बीच वास्तविक sharing, ताकि bounced cache line की लागत आप वास्तव में चुका रहे हों।
• एक ऐसा working set जो एक LLC के भीतर समा जाए, क्योंकि cache से बड़े process को move करके cache locality नहीं दी जा सकती।
• मशीन पर अतिरिक्त क्षमता (spare capacity), ताकि scheduler के पास यह चुनने का वास्तविक विकल्प हो कि अगला thread कहाँ रखना है।

और वे स्थितियाँ जहाँ कोई लाभ नहीं होता:

• एक मशीन जो पहले से ही पूर्ण क्षमता पर चल रही हो। हर CPU व्यस्त है, इसलिए placement मजबूरन करनी पड़ती है और बताए गए लाभ कम हो जाते हैं।
• Single threaded processes, और स्वतंत्र processes के pool जो कोई data share नहीं करते।
• एक working set जो LLC से काफी बड़ा हो, जिसे सावधानीपूर्वक की गई llc_aggr_tolerance setting जानबूझकर छोड़ देती है।
• एक ऐसा node जो केवल एक LLC रिपोर्ट करता है, जहाँ यह feature कभी चालू ही नहीं होता।

इसका एक लागत पक्ष भी है, और यह series इस बारे में स्पष्ट है। Occupancy एकत्रित करना task के context में किया जाने वाला कार्य है, और कुछ runs में request latency खराब होती दिखी क्योंकि उस कार्य ने task के user space में लौटने में देरी की। जहाँ औसत throughput में सुधार होता है, वहाँ भी aggregation से latency variance बढ़ सकता है। यदि आप औसत के बजाय tail latency की परवाह करते हैं, तो अपनी tail latency स्वयं मापें।

क्या VPS guest को यह सब दिखाई देता है

इसका उत्तर दो तथ्यों पर निर्भर करता है।

पहला, यह फीचर टोपोलॉजी पर आधारित है। Cache aware load balancing केवल तभी सक्षम होता है जब एक NUMA node के भीतर एक से अधिक LLC मौजूद हों, और kernel टोपोलॉजी सेटअप के दौरान इसे रिकॉर्ड करता है। जहाँ एक node केवल एक LLC की रिपोर्ट करता है, वहाँ cache aware path निष्क्रिय रहता है, चाहे tunables कैसे भी सेट किए गए हों।

दूसरा, आपका guest जो cache टोपोलॉजी देखता है, वह host की नहीं होती। यह वह टोपोलॉजी है जिसे hypervisor का CPU model प्रस्तुत करता है। एक डिफ़ॉल्ट KVM (kernel based virtual machine) guest को सामान्यतः host का वास्तविक L3 लेआउट नहीं दिया जाता है, इसलिए guest एक सरलीकृत तस्वीर के आधार पर निर्णय लेता है।

जाँचें कि आपका guest क्या देख रहा है:

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

index3 अधिकांश x86 CPUs पर L3 cache है। प्रत्येक vCPU को सूचीबद्ध करने वाली एक पंक्ति का अर्थ है कि guest एक एकल LLC देख रहा है, इसलिए इस फीचर के पास व्यवस्थित करने के लिए कुछ नहीं है। No such file or directory का अर्थ है कि guest के सामने कोई L3 expose ही नहीं किया गया है, और guest तब निचले cache स्तर को अपने अंतिम स्तर के रूप में मानता है, जिसकी सीमाएँ hypervisor द्वारा बनाई गई हैं, न कि silicon की वास्तविक सीमाएँ।

इसके बाद double scheduling आती है, जो किसी भी tenant के लिए एक स्पष्ट चेतावनी है। आपका guest kernel थ्रेड्स को vCPUs पर रखता है। host kernel उन vCPU थ्रेड्स को physical cores पर रखता है। एक guest जो सावधानीपूर्वक चार थ्रेड्स को vCPU 0 से 3 पर समूहबद्ध करता है, वह चार host थ्रेड्स के बारे में अपनी प्राथमिकता व्यक्त करता है, लेकिन host उन्हें अलग-अलग physical cache domains पर रखने और बाद में उन्हें स्थानांतरित करने के लिए स्वतंत्र है। guest का निर्णय गलत नहीं है, बस वह अंतिम निर्णय नहीं है। यह वही layer boundary है जो noisy neighbour द्वारा आपके vCPUs पर छोड़े गए steal time का कारण बनती है।

तो यह फीचर VPS tenant तक कहाँ पहुँचता है? दो स्थानों पर। उन plans पर जहाँ टोपोलॉजी synthetic के बजाय वास्तविक है, जैसे कि dedicated cores या passed-through लेआउट वाले बड़े instances, guest scheduler उस हार्डवेयर के बारे में निर्णय ले रहा है जो वास्तव में मौजूद है। और provider के अपने host kernel पर, जहाँ आपके vCPU थ्रेड्स की cache aware placement का लाभ provider को मिलता है, आपको नहीं। cache लेआउट आर्किटेक्चर के अनुसार भी भिन्न होता है, जो Arm VPS और x86 VPS की तुलना करते समय एक और महत्वपूर्ण कारक बन जाता है।

guest के भीतर cache व्यवहार को मापना bare metal की तुलना में कठिन है। perf stat -e cache-misses अक्सर <not supported> की रिपोर्ट करता है क्योंकि hypervisor PMU (performance monitoring unit) को guests के सामने expose नहीं करता है। इसके बजाय अपने स्वयं के application के throughput और latency को मापें, और दोनों runs के बीच स्विच करने के लिए debugfs knob का उपयोग करें।

जाँचें कि आपके kernel में CONFIG_SCHED_CACHE है या नहीं

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 का अर्थ है कि आपका kernel इसे सक्षम करके बनाया गया था। # CONFIG_SCHED_CACHE is not set वाली पंक्ति का अर्थ है कि उस version में यह विकल्प मौजूद है, लेकिन आपके distribution ने इसे बंद कर दिया है। यदि कोई output नहीं आता है, तो इसका मतलब है कि kernel उस विकल्प से पुराना है, और uname -r इसकी पुष्टि करेगा। कुछ minimal cloud images में /boot/config-* फ़ाइल नहीं होती है, वहाँ आप इसके बजाय zcat /proc/config.gz पढ़ सकते हैं, जो केवल तभी काम करता है जब kernel को CONFIG_IKCONFIG_PROC के साथ बनाया गया हो।

जब यह feature compile किया जाता है, तो ls पंक्ति llc_* tunables को print करती है। यदि CONFIG_SCHED_CACHE=y होने पर भी यह कुछ print नहीं करता है, तो पहले sudo mount -t debugfs none /sys/kernel/debug के साथ debugfs को mount करें।

अपने workload की तुलना feature के चालू और बंद होने पर करने के लिए, पहले वर्तमान मान (value) को record करें, क्योंकि आपको इसे वापस सेट करना होगा:

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

अपना benchmark चलाएँ, नोट किए गए मान को वापस लिखें, और इसे फिर से चलाएँ। Debugfs में किए गए बदलाव reboot के बाद सुरक्षित नहीं रहते हैं, जो कि परीक्षण के दौरान आप चाहते भी हैं।

डिस्ट्रिब्यूशन कर्नल में 7.2 कब आएगा

Mainline वह नहीं है जिसे आपका VPS बूट करता है। uname -r में मौजूद वर्ज़न आपके डिस्ट्रिब्यूशन से आता है, और हर डिस्ट्रिब्यूशन का mainline release से आपके सर्वर तक पहुँचने का अपना रास्ता होता है।

Fedora अपने सपोर्टेड लाइफ-साइकिल के दौरान अपने स्टेबल releases को नए mainline kernels पर rebase करता है, इसलिए वहां sudo dnf upgrade --refresh और एक रीबूट ही पूरी प्रक्रिया है, और आमतौर पर यह पहली जगह है जहाँ एक tenant नया कर्नल आज़मा सकता है। जब आप Fedora Server on a VPS चलाते हैं, तो यह cadence उसी का हिस्सा है जिसे आप चुन रहे होते हैं।

Ubuntu हर छह महीने के release के साथ एक नया कर्नल ships करता है, फिर उसे HWE (hardware enablement) stack के माध्यम से पिछले long term support (LTS) release तक ले जाता है। अगस्त 2026 तक, Ubuntu 24.04 LTS अभी भी अपने GA कर्नल के रूप में अप्रैल 2024 का 6.8 वर्ज़न इंस्टॉल करता है, जबकि इसका HWE stack अगस्त 2025 में 6.14 पर और फरवरी 2026 में 6.17 पर चला गया था। यह यथार्थवादी समय-सीमा है: अगस्त 2026 का एक mainline release लगभग एक साल बाद LTS HWE stack तक पहुँचता है।

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

Debian stable अपने release के पूरे जीवनकाल में एक ही कर्नल रखता है और backports के माध्यम से नए कर्नल प्रदान करता है, जिन्हें आप प्रति पैकेज चुन सकते हैं:

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

इनमें से किसी के भी बाद, रीबूट करें और uname -r तथा ऊपर दिए गए grep के साथ पुष्टि करें। एक नया कर्नल live-loadable नहीं होता है: live kernel patching on a VPS चलते हुए कर्नल में व्यक्तिगत फंक्शन्स के कोड को बदलता है, और यह structure layouts को नहीं बदल सकता या debugfs फाइलों को नहीं जोड़ सकता। Cache aware scheduling दोनों काम करता है, क्योंकि यह mm_struct में fields जोड़ता है, इसलिए यह केवल एक नया कर्नल बूट करने पर ही आता है।

दो व्यावहारिक फॉलो-अप। पुराने कर्नल को तब तक बूट करने योग्य रखें जब तक कि नया कर्नल आपके लोड को कुछ समय तक न संभाल ले, जिसके लिए pinning which kernel boots on a VPS का उपयोग किया जाता है। और /boot पर नज़र रखें, क्योंकि कुछ कर्नल अपग्रेड के बाद एक छोटा VPS बूट पार्टीशन भर जाता है, जैसा कि cleaning up old kernels on Ubuntu में बताया गया है।

ओनरशिप के बारे में एक आखिरी यथार्थवादी बात। KVM VPS पर guest कर्नल आपका होता है: आप इसे चुनते हैं, आप इसे बूट करते हैं, आप इसे रोल बैक करते हैं। होस्ट कर्नल आपके प्रोवाइडर का होता है, और आपके guest के अंदर की कोई भी सेटिंग यह नहीं बदल सकती कि हाइपरवाइजर कौन सा शेड्यूलर चलाता है। इसलिए शेड्यूलर प्लेसमेंट के बारे में release note एक tenant के लिए आधी कहानी ही है, और वह हिस्सा जिसे आप नियंत्रित करते हैं, वह guest साइड है।

इस पृष्ठ के लिए उपयोग किए गए स्रोत

• 16 अगस्त 2026 की release date और non-scheduler परिवर्तनों के लिए kernelnewbies.org पर 7.2 changelog सारांश।
• debugfs tunables, per-process preference mechanism और रिपोर्ट किए गए benchmark आंकड़ों के लिए lwn.net/Articles/1041668 और lwn.net/Articles/1058288 पर LWN की cache aware scheduling श्रृंखला की कवरेज।
• इस नियम के लिए कि cache aware load balancing को NUMA node में एक से अधिक LLC की आवश्यकता होती है, "sched/cache: Introduce sched_cache_present" पैच, जो topology पर इस feature को gate करता है।

पिछले release के लिए, Linux kernel 7.1 में क्या बदला देखें। version numbers यहाँ तक कैसे पहुँचे, इसके लिए Linux kernel इतिहास की समयरेखा देखें।

FAQ

क्या Linux 7.2 में cache aware scheduling एक VPS को तेज बनाती है?

आमतौर पर अपने आप में नहीं। यह फीचर केवल तब सक्रिय होता है जब एक NUMA node एक से अधिक last level cache की रिपोर्ट करता है, और एक सामान्य KVM guest को वह लेआउट नहीं दिखाया जाता है, इसलिए यह कोड कभी सक्रिय नहीं होता है। जहाँ यह सक्रिय होता है, वहाँ भी guest को दो बार schedule किया जाता है: आपका kernel एक vCPU चुनता है, और host kernel यह तय करता है कि वह vCPU thread किस physical core पर चलेगा, इसलिए guest-side cache निर्णय को host द्वारा बदला जा सकता है। अपने guest में cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u चलाएं। हर vCPU को कवर करने वाली एक लाइन का मतलब है कि फीचर के लिए व्यवस्थित करने जैसा कुछ नहीं है।

मैं यह कैसे जाँचूँ कि मेरे kernel में CONFIG_SCHED_CACHE है या नहीं?

grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) चलाएं। CONFIG_SCHED_CACHE=y का मतलब है कि यह built-in है, # CONFIG_SCHED_CACHE is not set का मतलब है कि आपके distribution ने इसे disable कर दिया है, और कोई आउटपुट न मिलने का मतलब है कि kernel इस विकल्प से पुराना है। यदि image में /boot/config-* फाइल नहीं है, तो zcat /proc/config.gz आज़माएं, जो केवल CONFIG_IKCONFIG_PROC के साथ बनाए गए kernels पर मौजूद होता है। आप रनटाइम पर sudo ls /sys/kernel/debug/sched/ | grep -i llc के साथ पुष्टि कर सकते हैं, जो फीचर मौजूद होने पर llc_* tunables को सूचीबद्ध करता है।

मैं reboot किए बिना cache aware scheduling को कैसे बंद करूँ?

tolerance knob में 0 लिखें: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'। यह रनटाइम पर फीचर को disable कर देता है, जो इसे benchmark के लिए एक साफ A/B स्विच बनाता है। पहले sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance के साथ वर्तमान मान पढ़ें और बाद में उसे वापस लिखें, क्योंकि defaults अलग-अलग builds में भिन्न होते हैं। debugfs में लिखा गया कुछ भी reboot के बाद नहीं बचता है। यदि cat में No such file or directory दिखाई देता है, तो आपके kernel में यह फीचर compile नहीं किया गया है और बंद करने के लिए कुछ भी नहीं है।

Ubuntu या Debian कब 7.2 आधारित kernel release करेंगे?

Fedora स्थिर releases को नए mainline kernels पर rebase करता है, इसलिए यह वहां सबसे पहले एक सामान्य dnf upgrade और reboot के माध्यम से आता है। Ubuntu हर छह महीने की release के साथ नए kernels जारी करता है और उन्हें HWE stack के माध्यम से पिछली LTS तक ले जाता है, और ऐतिहासिक अंतर लगभग एक वर्ष का है: अगस्त 2026 तक 24.04 LTS HWE stack फरवरी 2026 के 6.17 पर है जबकि इसका GA kernel अभी भी 6.8 है। Debian stable release के लिए एक kernel रखता है और trixie-backports के माध्यम से नए kernels प्रदान करता है, जिसे आप apt install -t trixie-backports linux-image-amd64 के साथ प्रति पैकेज install करते हैं।