ما الجديد في نواة Linux 7.2 لخوادم VPS؟

ما الجديد في نواة Linux 7.2

صدرت نواة Linux 7.2 في 16 أغسطس 2026، والتغيير الذي يستحق اهتمامك هو جدولة المهام الواعية بذاكرة التخزين المؤقت (cache aware scheduling)، والتي تم بناؤها خلف الخيار الجديد CONFIG_SCHED_CACHE. يحاول المجدول الآن إبقاء خيوط المعالجة (threads) الخاصة بعملية واحدة على وحدات معالجة مركزية (CPUs) تتشارك نفس مستوى ذاكرة التخزين المؤقت الأخير (LLC). لا يوجد أي تغيير آخر في هذا الإصدار يؤثر على كيفية توزيع أحمال العمل الخاصة بك على وحدة المعالجة المركزية.

بقية ميزات 7.2 باختصار: إعادة صياغة لمسار الالتزام السريع (fast commit) في نظام الملفات ext4، وتحسينات على MGLRU (كود استرداد الذاكرة متعدد الأجيال والأقل استخداماً مؤخراً)، وهدف جديد لمخطط الأجهزة dm-inlinecrypt لتشفير أجهزة الكتلة (block device) المضمن، وإزالة آخر استدعاء strncpy() من مصدر النواة.

هناك حقيقة واحدة تحدد ما إذا كانت الميزة الرئيسية مفيدة لك، لذا نذكرها أولاً. لا يتم تفعيل موازنة الحمل الواعية بذاكرة التخزين المؤقت إلا عندما تحتوي عقدة NUMA (الوصول غير المتماثل للذاكرة) على أكثر من ذاكرة LLC واحدة. عادةً لا يرى ضيف VPS هذا التخطيط، لذا في معظم الحالات يتم تجميع الكود ضمن النواة ولكنه لا يعمل أبداً. يتطلب التحقق من ذلك أمرين، تجدهما في قسم "هل يرى ضيف VPS أي شيء من هذا" أدناه.

كل ادعاء تقني في هذه الصفحة مستمد من سجل تغييرات 7.2 ومن سلسلة تصحيحات الجدولة الواعية بذاكرة التخزين المؤقت نفسها، والتي تمت قراءتها في 18 أغسطس 2026. المصادر مدرجة بالقرب من النهاية حتى تتمكن من مقارنتها بما تفعله نواتك الخاصة.

لماذا يحتاج المجدول إلى معرفة ذاكرات التخزين المؤقت

لا تحتوي مقابس الخوادم الحديثة على مستوى أخير واحد من ذاكرة التخزين المؤقت (LLC). تُبنى حزمة AMD EPYC من عدة مجمعات أنوية، ولكل مجمع ذاكرة L3 خاصة به. كما تقوم معالجات Intel Xeon الحديثة بتقسيم المقبس إلى أكثر من نطاق ذاكرة تخزين مؤقت. لذا، يمكن لعقدة NUMA واحدة أن تحتوي على أربع أو ثماني أو أكثر من ذاكرات LLC منفصلة، وقد ينتهي الأمر بخيطي معالجة (threads) لنفس البرنامج في نطاقين مختلفين.

هذا التوزيع يستهلك وقتاً. عندما يتشارك خيطا معالجة صفحة ذاكرة من ذاكرتي LLC مختلفتين، يحتفظ كل مخزن مؤقت بنسخة خاصة به من السطر. تؤدي عملية الكتابة على أحد الجانبين إلى إبطال النسخة الموجودة على الجانب الآخر، مما يضطر عملية القراءة التالية إلى عبور الوصلات البينية أو التوجه إلى الذاكرة الرئيسية. تُعرف هذه الظاهرة بـ "ارتداد ذاكرة التخزين المؤقت" (cache bouncing). تظهر هذه الحالة كدورات معالجة ضائعة في الانتظار، وليس كزمن خمول للمعالج، ولهذا السبب يسهل تجاهلها عند مراقبة متوسط الحمل (load average).

قبل الإصدار 7.2، كان موازن الحمل يوزع المهام بناءً على الحمل، ومعدل الاستخدام، والمعالجات الخاملة. لم يكن لديه أي مدخلات تشير إلى أن "هاتين المهمتين تقرآن نفس الذاكرة". يضيف الإصدار 7.2 هذه الميزة باستخدام تقريب لا يكلف شيئاً في الحساب: خيوط المعالجة التابعة لعملية واحدة تتشارك في مساحة عنوان واحدة، لذا يتم التعامل معها على أنها مرشحة لمشاركة البيانات.

كيف يختار النواة الـ LLC المفضل

يتم تتبع هذه العملية عبر mm_struct، وهو هيكل النواة الذي يمثل مساحة عنوان واحدة. تقوم النواة بأخذ عينات دورية لأماكن تشغيل خيوط المعالجة (threads) الخاصة بهذه العملية، وتحسب لكل LLC مقدار ما تشغله العملية فيه. يصبح الـ LLC الذي يحتوي على الجزء الأكبر هو الـ LLC المفضل للعملية بأكملها، وهذا الرقم الوحيد هو ما تقرأه القرارات اللاحقة.

يستخدم مساران هذا الرقم. عند الاستيقاظ، يوجّه المجدول اختياره للمعالج نحو الـ LLC المفضل للعملية بدلاً من اختيار أي معالج خامل في العقدة. أثناء موازنة الحمل، عندما يجب نقل المهام بين مجموعات المجدول، يفضل النظام نقل المهام التي تفضل بالفعل الـ LLC الوجهة، ويتجنب سحب مهمة بعيداً عن الـ LLC الذي تفضله.

تعتبر ضوابط الحماية بنفس أهمية الميزة نفسها، لأن حشر كل خيط معالجة لعملية مشغولة في نطاق ذاكرة تخزين مؤقت واحد قد يؤدي إلى تحميل زائد على ذلك النطاق بينما يظل باقي المقبس (socket) خاملاً. توجد الإعدادات القابلة للضبط في debugfs، وهو نظام ملفات التصحيح الخاص بالنواة، تحت المسار /sys/kernel/debug/sched/:

• llc_aggr_tolerance، قيمة من 0 إلى 100، تحدد مدى قوة تجميع النواة للمهام. 0 يعطل جدولة الوعي بذاكرة التخزين المؤقت أثناء التشغيل. 1 هو الإعداد الحذر: العملية التي يكون حجم ذاكرتها المقيمة (RSS) أكبر من الـ LLC، أو التي تشغل خيوط معالجة أكثر مما يمتلكه الـ LLC من أنوية، تُترك في مكانها. 100 يجمع المهام بغض النظر عن الحجم أو عدد خيوط المعالجة.
• llc_overload_pct، القيمة الافتراضية 50، هي متوسط الاستخدام الذي يُعتبر الـ LLC المفضل عنده مشغولاً.
• llc_imb_pct، القيمة الافتراضية 20، تضع حداً لعدم التوازن الذي قد تسببه عملية نقل تجميعية بمجرد تجاوز الـ LLC المفضل لنقطة التحميل الزائد تلك.
• llc_epoch_period، القيمة الافتراضية 10 ms، هي وتيرة جمع بيانات الإشغال.
• llc_epoch_affinity_timeout، القيمة الافتراضية 50 ms، هي المدة التي تحتفظ فيها العملية غير النشطة بتفضيلها قبل أن تسقطه النواة.

اقرأ قيمك الخاصة قبل تغيير أي منها، لأن توزيعات Linux قد تأتي بإعدادات افتراضية مختلفة: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

أحمال العمل التي تستفيد منطقياً، وتلك التي لا تستفيد

الأرقام أدناه هي النتائج المنشورة مع سلسلة الترقيعات، والتي تم قياسها على أجهزة خوادم، وبعضها مع ضبط خيار التفاوت (tolerance knob) على إعداد عدواني. اعتبر هذه الأرقام كأفضل سيناريو ممكن على العتاد المباشر (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 مع مجموعة واحدة بنسبة 30.57%، وتحسّن معدل نقل بيانات ChaCha20 على معالجات AMD Genoa بنسبة 44%. تم أخذ جميع نتائج 3 على خوادم ذات ذاكرة تخزين مؤقت (LLC) متعددة، والتي كان المختبِر يتحكم بها بالكامل.

يبدو شكل حمل العمل الذي يستفيد كما يلي:

• أكثر من خيط معالجة (thread) واحد في عملية واحدة، بحيث يوجد ما يمكن تجميعه.
• مشاركة حقيقية بين تلك الخيوط، بحيث تكون خطوط الذاكرة المرتدة (bounced cache line) تكلفة تدفعها فعلياً.
• مجموعة عمل (working set) تتسع داخل ذاكرة LLC واحدة، لأن العملية الأكبر من ذاكرة التخزين المؤقت لا يمكن منحها موضعية (locality) عبر نقلها.
• سعة فائضة على الجهاز، بحيث يمتلك المجدول خياراً حقيقياً حول مكان وضع خيط المعالجة التالي.

أما الحالات التي لا يوجد فيها أي مكاسب:

• جهاز يعمل بكامل طاقته بالفعل. كل وحدة معالجة مركزية مشغولة، لذا يكون التموضع إجبارياً وتتلاشى المكاسب المذكورة.
• عمليات أحادية الخيط، ومجموعات من العمليات المستقلة التي لا تتشارك في أي بيانات.
• مجموعة عمل أكبر بكثير من ذاكرة LLC، وهو ما يتجاهله إعداد llc_aggr_tolerance بعناية.
• عقدة (node) تبلغ عن وجود ذاكرة LLC واحدة، حيث لا تعمل هذه الميزة على الإطلاق.

هناك جانب تكلفة، والسلسلة شفافة بشأنه. جمع بيانات الإشغال (occupancy) هو عمل يتم في سياق المهمة، وأظهرت بعض التشغيلات تدهوراً في زمن استجابة الطلبات لأن هذا العمل أخّر عودة المهمة إلى مساحة المستخدم (user space). يمكن أن يؤدي التجميع أيضاً إلى زيادة تباين زمن الاستجابة حتى في الحالات التي يتحسن فيها متوسط معدل النقل. إذا كنت تهتم بالذيل (tail latency) بدلاً من المتوسط، فقم بقياس ذيل الأداء الخاص بك بنفسك.

هل يرى ضيف VPS أيّاً من هذا؟

هناك حقيقتان تحددان الإجابة.

أولاً، هذه الميزة مقيدة بالطوبولوجيا. لا يتم تفعيل موازنة الحمل المدركة لذاكرة التخزين المؤقت (Cache aware load balancing) إلا عند وجود أكثر من LLC واحد داخل عقدة NUMA واحدة، ويسجل النواة ذلك أثناء إعداد الطوبولوجيا. في الحالات التي تبلغ فيها العقدة عن وجود LLC واحد فقط، يظل المسار المدرك لذاكرة التخزين المؤقت غير نشط بغض النظر عن كيفية ضبط المتغيرات.

ثانياً، طوبولوجيا ذاكرة التخزين المؤقت التي يقرؤها ضيفك ليست طوبولوجيا المضيف. بل هي ما يقدمه نموذج وحدة المعالجة المركزية الخاص ببرنامج الـhypervisor. عادةً لا يتم منح ضيف KVM (kernel based virtual machine) افتراضي تخطيط L3 الحقيقي للمضيف، لذا يستنتج الضيف بناءً على صورة مبسطة.

تحقق مما يراه ضيفك:

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

index3 هو ذاكرة التخزين المؤقت L3 في معظم وحدات المعالجة المركزية x86. وجود سطر واحد يسرد كل vCPU يعني أن الضيف يرى LLC واحداً، وبالتالي لا توجد لدى الميزة أي شيء لترتبه. No such file or directory يعني أنه لم يتم كشف أي L3 للضيف على الإطلاق، وعندها يعامل الضيف مستوى ذاكرة تخزين مؤقت أدنى كمستوى أخير له، بحدود اخترعها الـhypervisor بدلاً من الحدود التي يفرضها العتاد (silicon).

ثم هناك الجدولة المزدوجة، وهي التحذير الصادق لأي مستأجر. تضع نواة الضيف الخيوط (threads) على vCPUs. وتضع نواة المضيف خيوط vCPU تلك على الأنوية الفيزيائية. الضيف الذي يجمع أربعة خيوط بعناية على vCPU من 0 إلى 3 قد عبّر عن تفضيل يتعلق بأربعة خيوط مضيفة، والمضيف حر في وضعها على نطاقات ذاكرة تخزين مؤقت فيزيائية مختلفة ونقلها لاحقاً. قرار الضيف ليس خاطئاً، لكنه ليس القرار النهائي. هذا هو نفس حد الطبقة الذي ينتج وقت السرقة (steal time) الذي يتركه جار مزعج على vCPUs الخاصة بك.

إذن، أين تصل هذه الميزة إلى مستأجر VPS؟ في مكانين. في الخطط التي تكون فيها الطوبولوجيا حقيقية وليست اصطناعية، مثل الأنوية المخصصة أو الحالات الأكبر ذات التخطيط الممرر (passed-through)، يتخذ مجدول الضيف قراراً بشأن عتاد موجود بالفعل. وفي نواة المضيف الخاصة بالمزود، حيث يكون التنسيق المدرك لذاكرة التخزين المؤقت لخيوط vCPU الخاصة بك مكسباً للمزود، وليس لك. يختلف تخطيط ذاكرة التخزين المؤقت أيضاً حسب البنية، وهو متغير إضافي عند مقارنة خادم Arm VPS بخادم x86 VPS.

قياس سلوك ذاكرة التخزين المؤقت داخل الضيف أصعب منه على العتاد المباشر (metal). غالباً ما يبلغ perf stat -e cache-misses عن <not supported> لأن الـhypervisor لا يكشف وحدة مراقبة الأداء (PMU) للضيوف. بدلاً من ذلك، قم بقياس الإنتاجية وزمن الوصول لتطبيقك الخاص، واستخدم مفتاح debugfs كأداة للتبديل بين التشغيلين.

تحقق مما إذا كان النواة لديك تحتوي على 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 أن النواة لديك بُنيت مع تفعيل هذا الخيار. السطر الذي يقرأ # CONFIG_SCHED_CACHE is not set يعني أن الخيار موجود في هذا الإصدار ولكن توزيعتك قامت بتعطيله. عدم ظهور أي مخرجات عادةً يعني أن النواة أقدم من هذا الخيار، وسيؤكد uname -r ذلك. بعض صور الأنظمة السحابية المصغرة لا تتضمن ملف /boot/config-*، وفي هذه الحالة تقرأ zcat /proc/config.gz بدلاً منه، وهو يعمل فقط عندما تكون النواة قد بُنيت مع CONFIG_IKCONFIG_PROC.

يطبع السطر ls إعدادات llc_* القابلة للضبط عند تجميع الميزة. إذا لم يطبع شيئاً بينما CONFIG_SCHED_CACHE=y، قم بتركيب debugfs أولاً باستخدام sudo mount -t debugfs none /sys/kernel/debug.

لمقارنة عبء العمل لديك مع تفعيل الميزة وتعطيلها، سجل القيمة الحالية أولاً، حيث ستحتاج إلى إعادتها لاحقاً:

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

شغّل اختبار الأداء الخاص بك، ثم أعد كتابة القيمة التي سجلتها، وشغّله مرة أخرى. عمليات الكتابة في debugfs لا تبقى بعد إعادة التشغيل، وهو ما تريده أثناء الاختبار.

متى ستدعم نواة التوزيعة الإصدار 7.2

الـ Mainline ليس هو ما يقلع به خادمك الافتراضي (VPS). الإصدار الموجود في uname -r يأتي من توزيعتك، ولكل توزيعة مسارها الخاص لنقل إصدارات الـ Mainline إلى خادمك.

تُحدّث Fedora إصداراتها المستقرة لتعتمد على أنوية Mainline جديدة خلال فترة دعمها، لذا فإن تنفيذ sudo dnf upgrade --refresh متبوعاً بإعادة تشغيل هو كل ما يتطلبه الأمر، وعادة ما تكون هذه التوزيعة هي المكان الأول الذي يمكن للمستخدم فيه تجربة نواة جديدة. هذا الإيقاع هو جزء مما تختاره عند تشغيل Fedora Server على خادم افتراضي.

تشحن Ubuntu نواة جديدة مع كل إصدار يصدر كل ستة أشهر، ثم تنقلها إلى إصدار الدعم طويل الأمد (LTS) السابق عبر حزمة HWE (تمكين العتاد). بحلول أغسطس 2026، لا تزال Ubuntu 24.04 LTS تثبّت الإصدار 6.8 (من أبريل 2024) كنواة GA، بينما انتقلت حزمة HWE الخاصة بها إلى 6.14 في أغسطس 2025 وإلى 6.17 في فبراير 2026. هذا هو الجدول الزمني الواقعي: إصدار Mainline من أغسطس 2026 يصل إلى حزمة LTS HWE بعد عام تقريباً.

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

تحتفظ Debian المستقرة بنواة واحدة طوال عمر الإصدار وتوفر أنوية أحدث عبر الـ 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 المذكور أعلاه. لا يمكن تحميل نواة جديدة أثناء التشغيل: تصحيح النواة المباشر على خادم افتراضي يستبدل كود دوال فردية في النواة العاملة، ولا يمكنه تغيير هياكل البيانات أو إضافة ملفات debugfs. جدولة المهام الواعية بالذاكرة المخبئية (Cache aware scheduling) تقوم بكليهما، لأنها تضيف حقولاً إلى mm_struct، لذا فهي تصل فقط عن طريق الإقلاع بنواة جديدة.

إليك خطوتان عمليتان للمتابعة. احتفظ بالنواة القديمة قابلة للإقلاع حتى تعمل النواة الجديدة تحت حمل عملك لفترة، وهذا هو الغرض من تثبيت نواة الإقلاع على خادم افتراضي. وراقب /boot، لأن قسم الإقلاع الصغير في الخادم الافتراضي يمتلئ بعد بضع ترقيات للنواة، كما هو موضح في تنظيف الأنوية القديمة على Ubuntu.

نقطة أخيرة حول الملكية. على خادم افتراضي من نوع KVM، نواة النظام الضيف هي ملكك: أنت تختارها، وأنت تقلع بها، وأنت تعيدها إلى الحالة السابقة. نواة المضيف (Host) تخص مزود الخدمة، ولا يوجد إعداد داخل نظامك الضيف يغير المجدول الذي يشغله الـ hypervisor. لذا فإن ملاحظات الإصدار المتعلقة بجدولة المهام هي نصف القصة فقط بالنسبة للمستأجر، والنصف الذي تتحكم فيه هو جانب النظام الضيف.

المصادر المستخدمة لهذه الصفحة

• ملخص سجل التغييرات للإصدار 7.2 على kernelnewbies.org، لمعرفة تاريخ الإصدار في 16 أغسطس 2026 والتغييرات غير المتعلقة بجدولة المهام.
• تغطية LWN لسلسلة جدولة المهام الواعية بالذاكرة المخبئية (cache aware scheduling) على lwn.net/Articles/1041668 وlwn.net/Articles/1058288، لمعرفة إعدادات debugfs القابلة للضبط، وآلية التفضيل لكل عملية، وأرقام الأداء المذكورة.
• التصحيح البرمجي الذي يقيّد الميزة بناءً على الطوبولوجيا، "sched/cache: Introduce sched_cache_present"، لمعرفة القاعدة التي تنص على أن موازنة الحمل الواعية بالذاكرة المخبئية تتطلب وجود أكثر من LLC واحد في عقدة NUMA.

للاطلاع على الإصدار السابق، راجع ما الذي تغير في نواة Linux 7.1. لمعرفة كيف وصلت أرقام الإصدارات إلى هنا، راجع الجدول الزمني لتاريخ نواة Linux.

FAQ

هل تجعل جدولة مراعاة ذاكرة التخزين المؤقت (cache aware scheduling) في Linux 7.2 خادم VPS أسرع؟

غالباً لا يحدث ذلك بمفرده. لا تُفعَّل هذه الميزة إلا عندما تُبلغ عقدة NUMA عن وجود أكثر من ذاكرة تخزين مؤقت من المستوى الأخير (last level cache)، ولا يظهر هذا التخطيط عادةً لضيوف KVM، لذا لا يعمل الكود البرمجي أبداً. في الحالات التي يعمل فيها، لا يزال الضيف يُجدول مرتين: يختار النواة الخاصة بك vCPU، بينما تقرر نواة المضيف أي نواة فيزيائية يعمل عليها خيط vCPU هذا، لذا يمكن للمضيف إلغاء أي قرار اتخذه الضيف بشأن ذاكرة التخزين المؤقت. نفّذ cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u داخل الضيف. إذا ظهر سطر واحد يغطي كل vCPU، فهذا يعني أنه لا يوجد شيء لتقوم الميزة بترتيبه.

كيف أتحقق مما إذا كانت النواة الخاصة بي تحتوي على CONFIG_SCHED_CACHE؟

نفّذ grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). تعني CONFIG_SCHED_CACHE=y أنها مدمجة، وتعني # CONFIG_SCHED_CACHE is not set أن توزيعتك قد عطلتها، وعدم ظهور أي مخرجات يعني أن النواة أقدم من هذا الخيار. إذا لم تحتوِ الصورة على ملف /boot/config-*، جرب zcat /proc/config.gz، الذي يوجد فقط في النوى المبنية باستخدام CONFIG_IKCONFIG_PROC. يمكنك التأكيد أثناء التشغيل باستخدام sudo ls /sys/kernel/debug/sched/ | grep -i llc، الذي يسرد متغيرات llc_* القابلة للضبط عند وجود الميزة.

كيف أوقف جدولة مراعاة ذاكرة التخزين المؤقت دون إعادة التشغيل؟

اكتب 0 في مقبض السماحية: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. هذا يعطل الميزة أثناء التشغيل، مما يجعلها مفتاح تبديل A/B نظيفاً لاختبار الأداء. اقرأ القيمة الحالية أولاً باستخدام sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance وأعد كتابتها لاحقاً، لأن القيم الافتراضية تختلف بين الإصدارات. لا شيء يُكتب في debugfs يبقى بعد إعادة التشغيل. إذا أبلغ cat عن No such file or directory، فهذا يعني أن النواة الخاصة بك لا تحتوي على الميزة مدمجة ولا يوجد شيء لإيقافه.

متى ستطرح Ubuntu أو Debian نواة مبنية على 7.2؟

تقوم Fedora بتحديث الإصدارات المستقرة إلى أنوية رئيسية جديدة، لذا تصل إليها أولاً عبر dnf upgrade عادي وإعادة تشغيل. تطرح Ubuntu أنوية جديدة مع كل إصدار يصدر كل ستة أشهر وتوفرها للإصدار LTS السابق عبر حزمة HWE، والفجوة التاريخية تقترب من عام: اعتباراً من أغسطس 2026، حزمة HWE لإصدار 24.04 LTS تعمل على 6.17 من فبراير 2026 بينما لا تزال نواتها الأساسية GA هي 6.8. تحتفظ Debian المستقرة بنواة واحدة للإصدار وتوفر أنوية أحدث عبر trixie-backports، والتي تثبتها لكل حزمة باستخدام apt install -t trixie-backports linux-image-amd64.