VPS-এ Linux kernel 7.2-এ নতুন কী

Linux kernel 7.2-এ নতুন কী

Linux kernel 7.2 16 August 2026-এ প্রকাশিত হয়েছে। আপনার নজর দেওয়ার মতো পরিবর্তন হলো cache-aware scheduling, যা নতুন CONFIG_SCHED_CACHE option-এর মাধ্যমে সক্রিয় করা হয়। Scheduler এখন একটি process-এর thread-গুলোকে এমন CPU-তে রাখার চেষ্টা করে, যেগুলো একই 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 সরানো হয়েছে।

একটি বিষয় নির্ধারণ করে headline feature আপনার কাজে লাগবে কি না। তাই সেটিই আগে বলা হচ্ছে। Cache-aware load balancing কেবল তখনই সক্রিয় হয়, যখন কোনো NUMA (non-uniform memory access) node-এ একাধিক LLC থাকে। VPS guest-এ সাধারণত এই layout দেখা যায় না। তাই অধিকাংশ guest-এ code compile করা থাকলেও তা কখনও সক্রিয় হয় না। নিচের “VPS guest কি এর কোনো অংশ দেখতে পায়” অংশে দুটি command দিয়ে এটি পরীক্ষা করা যায়।

এই পৃষ্ঠার প্রতিটি technical claim 7.2 changelog এবং cache-aware scheduling patch series থেকে নেওয়া হয়েছে; উভয়ই 18 August 2026-এ পরীক্ষা করা হয়েছিল। শেষের কাছাকাছি source-গুলোর তালিকা আছে। সেগুলো দেখে আপনার নিজের kernel-এর আচরণের সঙ্গে তথ্য মিলিয়ে নিতে পারবেন।

কেন scheduler-এর caches সম্পর্কে জানা প্রয়োজন ছিল

একটি আধুনিক server socket-এ একটি মাত্র last-level cache থাকে না। একটি AMD EPYC package কয়েকটি core complex নিয়ে তৈরি, এবং প্রতিটি complex-এর নিজস্ব L3 থাকে। সাম্প্রতিক Intel Xeon processor-গুলোও একটি socket-কে একাধিক cache domain-এ ভাগ করে। তাই একটি NUMA node-এ চারটি, আটটি বা তারও বেশি আলাদা LLC থাকতে পারে, এবং একই program-এর দুটি thread ভিন্ন LLC-তে চলতে পারে।

এই placement-এর কারণে সময় লাগে। দুটি thread ভিন্ন LLC থেকে একই page share করলে প্রতিটি cache সেই cache line-এর নিজস্ব copy রাখে। এক পাশে write হলে অন্য পাশের copy invalid করে দেওয়া হয়। ফলে পরবর্তী read-কে interconnect পার হতে হয়, অথবা main memory থেকে data পড়তে হয়। এটিই cache bouncing। এতে CPU অপেক্ষা করতে থাকা cycle হিসেবে সময় ব্যয় করে, CPU idle time হিসেবে নয়। তাই load average দেখার সময় বিষয়টি সহজে চোখ এড়িয়ে যায়।

7.2-এর আগে load balancer load, utilisation এবং idle CPU ব্যবহার করে task বসাত। "এই দুটি task একই memory পড়ে"—এমন কোনো তথ্য তার কাছে ছিল না। 7.2-এ এই তথ্য যোগ হয়েছে। এটি হিসাবের জন্য কোনো অতিরিক্ত খরচ ছাড়াই একটি approximation ব্যবহার করে: একটি process-এর thread-গুলো একই address space share করে, তাই ধরে নেওয়া হয় যে তারা সম্ভবত একই data share করে।

কার্নেল কীভাবে পছন্দের LLC নির্বাচন করে

এই tracking প্রক্রিয়ার সঙ্গে যুক্ত থাকে mm_struct-এ, যা একটি address space-কে উপস্থাপনকারী kernel structure। কার্নেল নির্দিষ্ট বিরতিতে পরীক্ষা করে সেই process-এর thread-গুলো কোথায় চলছে। এরপর প্রতিটি LLC অনুযায়ী গণনা করে, process-টির কতটা অংশ সেখানে চলছে। যে LLC-তে সবচেয়ে বেশি অংশ থাকে, সেটিই পুরো process-এর পছন্দের LLC হয়। পরবর্তী সিদ্ধান্তগুলো এই একক মানটি ব্যবহার করে।

এরপর দুটি path এটি ব্যবহার করে। wakeup-এর সময় scheduler node-এর যেকোনো idle CPU বেছে না নিয়ে process-এর পছন্দের LLC-র দিকে CPU নির্বাচনে অগ্রাধিকার দেয়। load balancing-এর সময় scheduler group-গুলোর মধ্যে task সরাতে হলে, destination LLC-কে ইতিমধ্যে পছন্দ করে এমন task সরানোর অগ্রাধিকার দেয়। একই সঙ্গে task-টিকে তার পছন্দের LLC থেকে সরানো এড়ায়।

এই feature-এর মতোই guardrail-গুলোও গুরুত্বপূর্ণ। কারণ ব্যস্ত একটি process-এর সব thread একটি cache domain-এ জড়ো করলে সেই domain অতিরিক্ত load-এ পড়তে পারে, যখন socket-এর বাকি অংশ idle থাকে। tunable-গুলো debugfs-এ থাকে। এটি kernel-এর debug filesystem। Path হলো /sys/kernel/debug/sched/:

• llc_aggr_tolerance, 0 থেকে 100 পর্যন্ত একটি মান, kernel কতটা aggressive ভাবে aggregation করবে তা নির্ধারণ করে। 0 runtime-এ cache-aware scheduling বন্ধ করে। 1 হলো সতর্ক সেটিং। কোনো process-এর RSS (resident set size, অর্থাৎ resident memory) LLC-এর চেয়ে বড় হলে, অথবা process-টি LLC-তে থাকা core-এর চেয়ে বেশি thread চালালে, সেটিকে বর্তমান অবস্থাতেই রাখা হয়। 100 size বা thread count নির্বিশেষে aggregation করে।
• llc_overload_pct-এর default মান 50। preferred LLC-কে busy হিসেবে গণনা করার আগে গড় utilisation কত হতে হবে, এটি তা নির্ধারণ করে।
• llc_imb_pct-এর default মান 20। preferred LLC ওই overload point অতিক্রম করার পর aggregation-ভিত্তিক migration সর্বোচ্চ কতটা imbalance তৈরি করতে পারবে, এটি তা সীমাবদ্ধ করে।
• llc_epoch_period-এর default মান 10 ms। occupancy কত ঘন ঘন সংগ্রহ করা হবে, এটি তা নির্ধারণ করে।
• llc_epoch_affinity_timeout-এর default মান 50 ms। inactive process-এর preference kernel বাতিল করার আগে কতক্ষণ ধরে রাখা হবে, এটি তা নির্ধারণ করে।

কোনো মান পরিবর্তনের আগে আপনার সিস্টেমের বর্তমান মানগুলো পড়ে নিন। কারণ distribution ভিন্ন default নিয়ে release হতে পারে: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance।

কোন ধরনের workload বাস্তবে সুবিধা পেতে পারে, আর কোনগুলো পাবে না

নিচের সংখ্যাগুলো patch series-এর সঙ্গে প্রকাশিত পরিমাপ। এগুলো server-class hardware-এ নেওয়া হয়েছিল, এবং কয়েকটি ক্ষেত্রে tolerance knob আক্রমণাত্মক setting-এ রাখা হয়েছিল। এগুলো bare metal-এ ভালো ফল পাওয়ার উদাহরণ হিসেবে দেখুন; আপনার server-এ একই ফল পাওয়ার প্রতিশ্রুতি হিসেবে নয়।

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

একটি group ব্যবহার করা Hackbench-এর ফল 30.57% উন্নত হয়েছে। AMD Genoa-তে ChaCha20 throughput run 44% উন্নত হয়েছে। মোট 3টি ফল multi-LLC server hardware-এ নেওয়া হয়েছিল, যা tester শুরু থেকে শেষ পর্যন্ত নিয়ন্ত্রণ করেছিল।

যে ধরনের workload সুবিধা পেতে পারে, তার বৈশিষ্ট্যগুলো হলো:

• একটি process-এ একাধিক thread থাকে, তাই সেগুলোকে group করার সুযোগ থাকে।
• ওই thread-গুলোর মধ্যে বাস্তব data sharing থাকে, তাই bounced cache line-এর খরচ আপনাকে সত্যিই দিতে হয়।
• Working set একটি LLC-এর মধ্যে ধরে, কারণ cache-এর চেয়ে বড় process-কে সরিয়ে cache locality দেওয়া যায় না।
• Machine-এ অতিরিক্ত capacity থাকে, তাই পরবর্তী thread কোথায় বসবে তা scheduler-এর সামনে বাস্তব বিকল্প থাকে।

আর যেসব ক্ষেত্রে লাভের সুযোগ নেই:

• Machine ইতিমধ্যে full capacity-তে চলছে। প্রতিটি CPU ব্যস্ত, তাই placement বাধ্যতামূলক হয় এবং প্রকাশিত লাভ কমে যায়।
• Single-threaded process এবং এমন independent process-এর pool, যেগুলো কোনো data share করে না।
• LLC-এর তুলনায় অনেক বড় working set, যা সতর্কতার সঙ্গে ব্যবহার করা llc_aggr_tolerance setting ইচ্ছাকৃতভাবে বাদ দেয়।
• এমন node যেখানে একটি LLC রিপোর্ট করা হয়। সেখানে feature কখনোই চালু হয় না।

এর একটি খরচও আছে, এবং series-টি তা স্পষ্টভাবে জানায়। Occupancy সংগ্রহের কাজ task-এর context-এ সম্পন্ন হয়। কিছু run-এ request latency বেড়েছে, কারণ এই কাজ task-টির user space-এ ফেরার সময় পিছিয়ে দিয়েছে। Average throughput বাড়লেও aggregation latency variance বাড়াতে পারে। Average নয়, tail latency গুরুত্বপূর্ণ হলে নিজের workload-এর tail latency মাপুন।

VPS guest কি এর কোনোটি দেখতে পায়

দুটি বিষয় উত্তর নির্ধারণ করে।

প্রথমত, এই feature topology-নির্ভর। একটি NUMA node-এর ভেতরে একটির বেশি LLC থাকলেই cache aware load balancing সক্রিয় হয়, এবং topology setup-এর সময় kernel তা নথিভুক্ত করে। কোনো node যদি একটি মাত্র LLC রিপোর্ট করে, tunable যেভাবেই সেট করা হোক না কেন cache aware path নিষ্ক্রিয় থাকে।

দ্বিতীয়ত, guest যে cache topology পড়ে, তা host-এর topology নয়। Hypervisor-এর CPU model যা উপস্থাপন করে, guest সেটিই দেখে। একটি default KVM (kernel based virtual machine) guest-কে সাধারণত host-এর প্রকৃত L3 layout দেওয়া হয় না। তাই guest একটি সরলীকৃত topology ধরে সিদ্ধান্ত নেয়।

আপনার guest কী দেখছে তা পরীক্ষা করুন:

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

বেশিরভাগ x86 CPU-তে index3 হলো L3 cache। একটি line-এ সব vCPU-এর তালিকা থাকলে guest একটি single LLC দেখছে। তাই feature-টির সাজানোর মতো কিছু নেই। No such file or directory বোঝায় guest-এর কাছে কোনো L3 প্রকাশ করা হয়নি। তখন guest একটি নিম্ন cache level-কে শেষ cache level হিসেবে ধরে। এর boundary silicon-এর নয়, hypervisor-এর তৈরি।

এরপর আছে double scheduling। যেকোনো tenant-এর ক্ষেত্রে এটিই বাস্তব সীমাবদ্ধতা। আপনার guest kernel thread-গুলোকে vCPU-তে বসায়। Host kernel সেই vCPU thread-গুলোকে physical core-এ বসায়। কোনো guest চারটি thread-কে vCPU 0 থেকে 3-এ একসঙ্গে রাখলে, guest চারটি host thread সম্পর্কে একটি পছন্দ জানিয়েছে। কিন্তু host সেগুলোকে ভিন্ন physical cache domain-এ রাখতে পারে এবং পরে সরিয়েও দিতে পারে। Guest-এর সিদ্ধান্ত ভুল নয়। তবে সেটিই চূড়ান্ত সিদ্ধান্ত নয়। এই একই layer boundary-এর কারণে noisy neighbour আপনার vCPU-তে যে steal time রেখে যায়।

তাহলে এই feature VPS tenant-এর ক্ষেত্রে কোথায় কার্যকর হয়? দুটি জায়গায়। যেসব plan-এ topology synthetic নয়, বরং বাস্তব—যেমন dedicated core বা passed-through layout-সহ বড় instance—সেখানে guest scheduler বাস্তবে থাকা hardware সম্পর্কে সিদ্ধান্ত নিচ্ছে। আর provider-এর নিজস্ব host kernel-এ, যেখানে আপনার vCPU thread-এর cache aware placement provider-এর সুবিধা, আপনার নয়। Architecture অনুযায়ী cache layout-ও ভিন্ন হয়। তাই Arm VPS ও x86 VPS-এর তুলনা করার সময় এটি আরও একটি পরিবর্তনশীল।

Guest-এর ভেতরে cache behavior মাপা bare metal-এর তুলনায় কঠিন। Hypervisor guest-দের কাছে PMU (performance monitoring unit) প্রকাশ না করায় perf stat -e cache-misses প্রায়ই <not supported> রিপোর্ট করে। এর বদলে আপনার নিজের application-এর throughput ও latency মাপুন। দুটি run-এর মধ্যে পরিবর্তন করার switch হিসেবে 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-এ এটি সক্রিয় করে build করা হয়েছে। # CONFIG_SCHED_CACHE is not set লেখা একটি লাইন থাকলে বুঝবেন, ওই version-এ option-টি আছে, কিন্তু আপনার distribution এটি বন্ধ রেখেছে। একেবারেই কোনো output না থাকলে সাধারণত বুঝতে হবে, kernel-টি option যুক্ত হওয়ার আগের version-এর। uname -r এটি নিশ্চিত করবে। কিছু minimal cloud image-এ /boot/config-* file থাকে না। সে ক্ষেত্রে zcat /proc/config.gz পড়ুন। এটি কেবল তখনই কাজ করে, যখন kernel-টি CONFIG_IKCONFIG_PROC দিয়ে build করা হয়েছে।

Feature-টি compile করা থাকলে ls line তার llc_* tunable-গুলোর মান দেখায়। CONFIG_SCHED_CACHE=y থাকা সত্ত্বেও কোনো output না এলে আগে sudo mount -t debugfs none /sys/kernel/debug দিয়ে debugfs mount করুন।

Feature চালু ও বন্ধ অবস্থায় আপনার workload তুলনা করতে প্রথমে বর্তমান মানটি সংরক্ষণ করুন। কারণ পরে সেটি আগের মানে ফিরিয়ে দিতে হবে:

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

আপনার benchmark চালান। এরপর সংরক্ষিত মানটি আবার লিখে দিয়ে benchmark পুনরায় চালান। Debugfs-এ করা write reboot-এর পর টিকে থাকে না। পরীক্ষার সময় এটিই প্রত্যাশিত আচরণ।

কোন distribution kernel-এ 7.2 আসবে

Mainline kernel আপনার VPS যে kernel boot করে, সেটি নয়। uname -r-এ থাকা version আপনার distribution থেকে এসেছে। প্রতিটি distribution mainline release থেকে আপনার server পর্যন্ত পৌঁছানোর জন্য আলাদা পদ্ধতি ব্যবহার করে।

Fedora তার supported life চলাকালে stable release-গুলোকে নতুন mainline kernel-এ rebase করে। তাই সেখানে sudo dnf upgrade --refresh চালিয়ে reboot করাই পুরো প্রক্রিয়া। নতুন kernel চেষ্টা করার জন্য tenant সাধারণত প্রথমে Fedora-তেই সুযোগ পায়। VPS-এ Fedora Server চালানো বেছে নেওয়ার সময় এই release cadence-ও বিবেচনায় থাকে।

Ubuntu প্রতি ছয় মাসের release-এর সঙ্গে নতুন kernel দেয়। এরপর HWE (hardware enablement) stack-এর মাধ্যমে আগের long term support (LTS) release-এ সেটি নিয়ে আসে। August 2026 পর্যন্ত Ubuntu 24.04 LTS এখনও April 2024-এর 6.8-কে GA kernel হিসেবে install করে। তবে এর HWE stack August 2025-এ 6.14 এবং February 2026-এ 6.17-এ গিয়েছে। বাস্তব সময়সীমা এমনই: August 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-এর পুরো life cycle-এ একটি kernel বজায় রাখে। backports-এর মাধ্যমে আরও নতুন kernel দেয়। প্রতিটি package-এর জন্য আপনাকে এটি আলাদাভাবে enable করতে হয়:

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

এর যেকোনো একটি করার পরে reboot করুন। তারপর uname -r এবং উপরের grep দিয়ে নিশ্চিত করুন। নতুন kernel live-load করা যায় না: VPS-এ live kernel patching চলমান kernel-এর পৃথক function-এর code প্রতিস্থাপন করে। এটি structure layout পরিবর্তন করতে বা debugfs file যোগ করতে পারে না। Cache aware scheduling দুটিই করে। কারণ এটি mm_struct-এ field যোগ করে। তাই এটি কেবল নতুন kernel boot করার মাধ্যমেই কার্যকর হয়।

এখানে দুটি ব্যবহারিক পরবর্তী কাজ আছে। নতুন kernel কিছু সময় আপনার load সামলানো পর্যন্ত পুরোনো kernel-টি boot করার উপযোগী রাখুন। VPS-এ কোন kernel boot হবে তা pin করা এই কাজের জন্যই। এছাড়া /boot পর্যবেক্ষণ করুন। কয়েকবার kernel upgrade-এর পর ছোট VPS-এর boot partition পূর্ণ হয়ে যেতে পারে। Ubuntu-তে পুরোনো kernel পরিষ্কার করা-তে এটি ব্যাখ্যা করা হয়েছে।

Ownership সম্পর্কে আরেকটি বাস্তব বিষয় আছে। KVM VPS-এ guest kernel আপনার নিয়ন্ত্রণে থাকে। আপনি এটি নির্বাচন করেন, boot করেন এবং প্রয়োজনে rollback করেন। host kernel আপনার provider-এর। আপনার guest-এর কোনো setting hypervisor কোন scheduler চালাবে, তা পরিবর্তন করতে পারে না। তাই scheduler placement সম্পর্কে কোনো release note tenant-এর জন্য কেবল অর্ধেক বিষয় ব্যাখ্যা করে। আপনি যে অর্ধেক নিয়ন্ত্রণ করেন, সেটি guest side।

এই পৃষ্ঠার জন্য ব্যবহৃত উৎস

• 16 August 2026-এর release date এবং scheduler-বহির্ভূত পরিবর্তনগুলোর জন্য kernelnewbies.org-এ থাকা 7.2 changelog summary।
• debugfs tunable, প্রতি-process preference mechanism এবং প্রকাশিত benchmark figure-এর জন্য lwn.net/Articles/1041668 এবং lwn.net/Articles/1058288-এ LWN-এর cache-aware scheduling series সম্পর্কিত coverage।
• topology-এর ওপর feature-টি নির্ভরশীল করার patch, "sched/cache: Introduce sched_cache_present", যেখানে বলা হয়েছে যে cache-aware load balancing-এর জন্য একটি NUMA node-এ একটির বেশি LLC প্রয়োজন।

আগের release-এর জন্য দেখুন Linux kernel 7.1-এ কী পরিবর্তন হয়েছে। Version number কীভাবে এখানে এসেছে, তা জানতে দেখুন Linux kernel history timeline।

FAQ

Linux 7.2-এ cache aware scheduling কি VPS-কে দ্রুত করে?

সাধারণত, শুধু এটি চালু থাকলে নয়। কোনো NUMA node একাধিক last level cache রিপোর্ট করলেই এই feature সক্রিয় হয়। সাধারণ KVM guest-এ এই layout দেখানো হয় না। তাই code কখনো সক্রিয় হয় না। যেখানে এটি সক্রিয় হয়, সেখানেও guest-কে দুইবার schedule করা হয়। আপনার kernel একটি vCPU বেছে নেয়। এরপর host kernel নির্ধারণ করে, সেই vCPU thread কোন physical core-এ চলবে। তাই guest-এর cache-সংক্রান্ত সিদ্ধান্ত host বাতিল করে দিতে পারে। আপনার guest-এ cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u চালান। প্রতিটি vCPU-কে কভার করে একটি মাত্র line থাকলে feature-টির ব্যবস্থা করার মতো কিছু থাকে না।

আমার 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 এটি disabled করেছে, এবং কোনো output না থাকলে kernel-টি option-টির চেয়ে পুরোনো। image-এ /boot/config-* file না থাকলে zcat /proc/config.gz চেষ্টা করুন। এটি শুধু CONFIG_IKCONFIG_PROC দিয়ে built করা kernel-এ থাকে। feature উপস্থিত থাকলে sudo ls /sys/kernel/debug/sched/ | grep -i llc দিয়ে runtime-এ নিশ্চিত হতে পারেন। এটি llc_* tunable তালিকাভুক্ত করে।

reboot না করে cache aware scheduling কীভাবে বন্ধ করব?

tolerance knob-এ 0 লিখুন: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'। এতে runtime-এ feature-টি disabled হয়। Benchmark-এর জন্য এটি একটি পরিষ্কার A/B switch হিসেবে ব্যবহার করা যায়। প্রথমে sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance দিয়ে বর্তমান value পড়ুন এবং পরে সেটি আবার লিখুন, কারণ build অনুযায়ী default ভিন্ন হতে পারে। debugfs-এ লেখা কোনো value reboot-এর পর থাকে না। cat যদি No such file or directory রিপোর্ট করে, আপনার kernel-এ feature-টি compiled in নেই। তাই বন্ধ করার মতো কিছু নেই।

Ubuntu বা Debian কখন 7.2-ভিত্তিক kernel release করবে?

Fedora stable release-গুলোকে নতুন mainline kernel-এ rebase করে। তাই সাধারণ dnf upgrade এবং reboot-এর মাধ্যমে এটি সেখানে আগে আসে। Ubuntu প্রতি ছয় মাসের release-এর সঙ্গে নতুন kernel দেয় এবং HWE stack-এর মাধ্যমে আগের LTS-এও তা সরবরাহ করে। ঐতিহাসিক ব্যবধান প্রায় এক বছর। August 2026 অনুযায়ী, 24.04 LTS HWE stack February 2026-এর 6.17-এ রয়েছে, আর এর GA kernel এখনও 6.8। Debian stable release-এর জন্য একটি kernel রাখে এবং trixie-backports-এর মাধ্যমে নতুন kernel দেয়। প্রতি package-এর জন্য apt install -t trixie-backports linux-image-amd64 ব্যবহার করে এটি install করতে হয়।