ویژگی‌های جدید هسته لینوکس 7.2 برای سرور VPS

ویژگی‌های جدید در هسته لینوکس 7.2

هسته لینوکس 7.2 در تاریخ 16 اوت 2026 منتشر شد و تغییری که شایسته توجه شماست، زمان‌بندی آگاه از کش (cache aware scheduling) است که پشت گزینه جدید CONFIG_SCHED_CACHE پیاده‌سازی شده است. زمان‌بند (scheduler) اکنون تلاش می‌کند رشته‌های یک پردازش را روی CPUهایی نگه دارد که از یک کش سطح آخر (LLC) مشترک استفاده می‌کنند. هیچ مورد دیگری در این نسخه، نحوه قرارگیری بار کاری شما روی CPU را تغییر نمی‌دهد.

بقیه تغییرات نسخه 7.2 در یک نگاه: بازنگری در مسیر fast commit فایل‌سیستم ext4، بهبودهایی در MGLRU (کد بازیابی حافظه چندنسلی با الگوریتم least recently used)، یک هدف (target) جدید در device mapper با نام dm-inlinecrypt برای رمزنگاری inline بلوک‌های دستگاه، و حذف آخرین فراخوانی strncpy() از سورس‌کد هسته.

یک واقعیت تعیین می‌کند که آیا ویژگی اصلی این نسخه برای شما کاربردی دارد یا خیر، بنابراین ابتدا به آن می‌پردازیم. متعادل‌سازی بار آگاه از کش تنها زمانی فعال می‌شود که یک گره NUMA (دسترسی غیریکسان به حافظه) بیش از یک LLC داشته باشد. یک مهمان VPS معمولاً چنین ساختاری را مشاهده نمی‌کند، بنابراین در اکثر سیستم‌های مهمان، این کد کامپایل می‌شود اما هرگز فعال نمی‌گردد. بررسی این موضوع به دو دستور نیاز دارد که در بخش «آیا یک مهمان VPS این ویژگی را می‌بیند» در ادامه آمده است.

تمام ادعاهای فنی در این صفحه از لاگ تغییرات 7.2 و خود سری وصله‌های زمان‌بندی آگاه از کش استخراج شده و در تاریخ 18 اوت 2026 مطالعه شده‌اند. منابع در انتهای صفحه فهرست شده‌اند تا بتوانید آن‌ها را با آنچه هسته فعلی شما انجام می‌دهد، مطابقت دهید.

چرا زمان‌بند (scheduler) باید از وضعیت کش‌ها آگاه باشد

یک سوکت سرور مدرن، تنها یک کش سطح آخر (LLC) ندارد. یک پکیج AMD EPYC از چندین مجتمع هسته (core complex) ساخته شده است و هر مجتمع، L3 اختصاصی خود را دارد. پردازنده‌های جدید Intel Xeon نیز یک سوکت را به بیش از یک دامنهٔ کش تقسیم می‌کنند. بنابراین، یک گره NUMA واحد می‌تواند شامل چهار، هشت یا تعداد بیشتری LLC مجزا باشد و دو ترد از یک برنامه ممکن است در دامنه‌های متفاوتی قرار بگیرند.

این جای‌گذاری هزینهٔ زمانی دارد. هنگامی که دو ترد یک صفحه حافظه را از LLCهای متفاوت به اشتراک می‌گذارند، هر کش کپی مخصوص به خود را از آن خط (line) نگه می‌دارد. یک عملیات نوشتن در یک سمت، کپی موجود در سمت دیگر را نامعتبر می‌کند؛ بنابراین خواندن بعدی باید از طریق interconnect انجام شود یا به حافظهٔ اصلی برود. این پدیده cache bouncing نام دارد. این وضعیت به صورت چرخه‌های هدررفته در انتظار (waiting) ظاهر می‌شود، نه به عنوان زمان بیکاری CPU؛ به همین دلیل است که هنگام مشاهدهٔ load average، تشخیص آن آسان نیست.

پیش از نسخه 7.2، متعادل‌کنندهٔ بار (load balancer) وظایف را بر اساس بار کاری، میزان استفاده و CPUهای بیکار توزیع می‌کرد. هیچ ورودی وجود نداشت که بگوید «این دو وظیفه از حافظهٔ یکسانی می‌خوانند». نسخه 7.2 قابلیتی را اضافه کرده است که از یک تقریب با هزینهٔ محاسباتی صفر استفاده می‌کند: ترد‌های یک پردازش، فضای آدرس یکسانی را به اشتراک می‌گذارند، بنابراین فرض می‌شود که احتمالاً داده‌های مشترکی دارند.

نحوه انتخاب LLC ترجیحی توسط هسته

این ردیابی به پردازش وابسته است و در mm_struct، یعنی ساختار هسته که نمایانگر یک فضای آدرس است، ذخیره می‌شود. هسته به‌طور دوره‌ای نمونه‌برداری می‌کند که ترد‌های آن پردازش در کجا اجرا می‌شوند و به ازای هر LLC، محاسبه می‌کند که چه مقدار از پردازش در هر کدام قرار دارد. LLCای که بیشترین سهم را داشته باشد، به عنوان LLC ترجیحی برای کل پردازش انتخاب می‌شود و همین عدد واحد است که تصمیمات بعدی بر اساس آن اتخاذ می‌گردند.

سپس دو مسیر از این مقدار استفاده می‌کنند. هنگام بیدار شدن (wakeup)، زمان‌بند (scheduler) انتخاب CPU خود را به سمت LLC ترجیحی پردازش متمایل می‌کند، به‌جای آنکه هر CPU بیکاری را در گره (node) انتخاب کند. در حین توازن بار (load balancing)، زمانی که وظایف باید بین گروه‌های زمان‌بند جابه‌جا شوند، اولویت با انتقال وظایفی است که از قبل LLC مقصد را ترجیح می‌دهند و از جدا کردن یک وظیفه از LLC ترجیحی‌اش اجتناب می‌شود.

حفاظ‌ها (guardrails) به اندازه خود قابلیت اهمیت دارند، زیرا متراکم کردن تمام ترد‌های یک پردازش پرمشغله در یک دامنه کش (cache domain) می‌تواند باعث شود آن دامنه بیش از حد بارگذاری شود، در حالی که بقیه سوکت بیکار می‌ماند. پارامترهای قابل تنظیم در debugfs، یعنی فایل‌سیستم دیباگ هسته، تحت مسیر /sys/kernel/debug/sched/ قرار دارند:

• llc_aggr_tolerance، مقداری از 0 تا 100، تعیین می‌کند که هسته با چه شدتی تجمیع (aggregate) را انجام دهد. 0 زمان‌بندی آگاه از کش (cache aware scheduling) را در زمان اجرا غیرفعال می‌کند. 1 تنظیم محتاطانه است: پردازشی که RSS (اندازه مجموعه مقیم، یعنی حافظه مقیم آن) بزرگتر از LLC باشد، یا ترد‌های بیشتری نسبت به هسته‌های موجود در LLC اجرا کند، در همان‌جایی که هست باقی می‌ماند. 100 فارغ از اندازه یا تعداد ترد، تجمیع را انجام می‌دهد.
• llc_overload_pct، با مقدار پیش‌فرض 50، میانگین بهره‌وری است که بالاتر از آن، LLC ترجیحی به عنوان شلوغ (busy) در نظر گرفته می‌شود.
• 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.

کدام بار کاری سود می‌برد و کدام نه

اعداد زیر ارقامی هستند که همراه با مجموعه پچ منتشر شده‌اند و روی سخت‌افزار کلاس سرور اندازه‌گیری شده‌اند؛ برخی از آن‌ها با تنظیمات تهاجمی برای پارامتر tolerance به دست آمده‌اند. این اعداد را به عنوان بهترین حالت روی سخت‌افزار 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 نتیجه روی سخت‌افزار سرور multi-LLC که تحت کنترل کامل تست‌کننده بود، ثبت شده‌اند.

ویژگی‌های یک بار کاری که از این قابلیت سود می‌برد به شرح زیر است:

• بیش از یک thread در یک پردازش واحد، تا چیزی برای گروه‌بندی وجود داشته باشد.
• اشتراک‌گذاری واقعی بین آن threadها، به‌طوری که bounce شدن cache line هزینه‌ای باشد که واقعاً می‌پردازید.
• مجموعه کاری (working set) که در یک LLC جا می‌شود، زیرا پردازشی که بزرگ‌تر از کش است را نمی‌توان با جابه‌جایی به موقعیت بهتری از نظر کش رساند.
• ظرفیت خالی روی ماشین، تا scheduler انتخاب واقعی برای محل قرارگیری thread بعدی داشته باشد.

و مواردی که هیچ سودی در آن‌ها وجود ندارد:

• ماشینی که در حال حاضر با ظرفیت کامل کار می‌کند. تمام CPUها مشغول هستند، بنابراین جای‌گذاری اجباری است و بهبودهای گزارش‌شده از بین می‌روند.
• پردازش‌های تک‌رشته‌ای (single-threaded) و مجموعه‌ای از پردازش‌های مستقل که هیچ داده‌ای را به اشتراک نمی‌گذارند.
• مجموعه کاری بسیار بزرگ‌تر از LLC، که تنظیم دقیق llc_aggr_tolerance به‌طور عمدی از آن صرف‌نظر می‌کند.
• گره‌ای که تنها یک LLC گزارش می‌کند، جایی که این قابلیت اصلاً فعال نمی‌شود.

این موضوع جنبه هزینه‌ای نیز دارد و مجموعه پچ‌ها در مورد آن شفاف است. جمع‌آوری میزان اشغال (occupancy) کاری است که در context همان task انجام می‌شود و برخی اجراها نشان داد که تأخیر درخواست (request latency) بدتر شده است، زیرا آن کار باعث تأخیر در بازگشت task به فضای کاربر (user space) شده است. تجمیع داده‌ها همچنین می‌تواند واریانس تأخیر را افزایش دهد، حتی در مواردی که میانگین نرخ انتقال بهبود یافته است. اگر به جای میانگین، به دنبال بررسی tail latency هستید، آن را برای سیستم خود اندازه‌گیری کنید.

آیا یک مهمان VPS این موارد را مشاهده می‌کند

دو واقعیت پاسخ این پرسش را تعیین می‌کنند.

نخست، این قابلیت به توپولوژی وابسته است. Load balancing آگاه از کش (cache aware) تنها زمانی فعال می‌شود که بیش از یک LLC در داخل یک گره NUMA وجود داشته باشد و هسته (kernel) این موضوع را در حین تنظیم توپولوژی ثبت کند. در مواردی که یک گره تنها یک LLC را گزارش می‌کند، مسیر آگاه از کش غیرفعال باقی می‌ماند؛ فارغ از اینکه تنظیمات چگونه پیکربندی شده باشند.

دوم، توپولوژی کش که مهمان شما می‌بیند، توپولوژی میزبان نیست. این توپولوژی همان چیزی است که مدل CPU هایپروایزر ارائه می‌دهد. یک مهمان پیش‌فرض KVM (ماشین مجازی مبتنی بر هسته) معمولاً طرح واقعی L3 میزبان را دریافت نمی‌کند، بنابراین مهمان بر اساس یک تصویر ساده‌شده تصمیم‌گیری می‌کند.

بررسی کنید که مهمان شما چه چیزی را مشاهده می‌کند:

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

index3 در اکثر CPUهای x86 همان کش L3 است. یک خط که تمام vCPUها را فهرست می‌کند به این معنی است که مهمان یک LLC واحد می‌بیند، بنابراین این قابلیت چیزی برای مدیریت ندارد. No such file or directory به این معنی است که هیچ L3ای به مهمان ارائه نشده است و مهمان در این حالت یک سطح کش پایین‌تر را به عنوان آخرین سطح در نظر می‌گیرد، با مرزهایی که هایپروایزر ابداع کرده است، نه مرزهایی که در سیلیکون وجود دارد.

سپس مسئله double scheduling مطرح می‌شود که یک هشدار صادقانه برای هر مستأجر (tenant) است. هسته مهمان شما تردها را روی vCPUها قرار می‌دهد. هسته میزبان آن ترد‌های vCPU را روی هسته‌های فیزیکی قرار می‌دهد. مهمانی که با دقت چهار ترد را روی vCPUهای 0 تا 3 گروه‌بندی می‌کند، ترجیحی را در مورد چهار ترد میزبان ابراز کرده است، اما میزبان آزاد است که آن‌ها را در دامنه‌های کش فیزیکی متفاوتی قرار دهد و بعداً آن‌ها را جابه‌جا کند. تصمیم مهمان اشتباه نیست، فقط تصمیم نهایی نیست. این همان مرز لایه‌ای است که باعث ایجاد زمان steal که یک همسایه پرسر و صدا روی vCPUهای شما باقی می‌گذارد می‌شود.

بنابراین این قابلیت کجا به یک مستأجر VPS می‌رسد؟ در دو جا. در طرح‌هایی که توپولوژی واقعی است و نه مصنوعی، مانند هسته‌های اختصاصی یا نمونه‌های بزرگ‌تر با طرح passed-through، زمان‌بند مهمان در حال تصمیم‌گیری در مورد سخت‌افزاری است که وجود دارد. و در هسته میزبان خودِ ارائه‌دهنده، جایی که قرارگیری آگاه از کش برای ترد‌های vCPU شما، دستاورد ارائه‌دهنده است، نه شما. طرح‌بندی کش همچنین بر اساس معماری متفاوت است، که هنگام مقایسه یک VPS مبتنی بر Arm با یک VPS مبتنی بر x86 یک متغیر دیگر محسوب می‌شود.

اندازه‌گیری رفتار کش در داخل یک مهمان دشوارتر از سخت‌افزار فیزیکی (bare metal) است. perf stat -e cache-misses اغلب <not supported> را گزارش می‌کند، زیرا هایپروایزر PMU (واحد نظارت بر عملکرد) را در اختیار مهمانان قرار نمی‌دهد. در عوض، throughput و latency برنامه خود را اندازه‌گیری کنید و از سوئیچ 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 مونت کنید.

برای مقایسه عملکرد workload خود در حالت فعال و غیرفعال بودن این قابلیت، ابتدا مقدار فعلی را یادداشت کنید تا بتوانید آن را به حالت اول بازگردانید:

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

بنچمارک خود را اجرا کنید، مقداری که یادداشت کرده بودید را دوباره اعمال کنید و بنچمارک را مجدداً اجرا نمایید. تغییرات در debugfs پس از reboot باقی نمی‌مانند که این دقیقاً همان چیزی است که هنگام تست به آن نیاز دارید.

چه زمانی هسته توزیع‌ها به نسخه 7.2 می‌رسد

آنچه VPS شما با آن بوت می‌شود، لزوماً نسخه Mainline نیست. نسخه‌ای که در uname -r مشاهده می‌کنید، توسط توزیع شما ارائه شده است و هر توزیع مسیر خاص خود را برای انتقال از یک نسخه Mainline به سرور شما دارد.

Fedora در طول دوره پشتیبانی نسخه‌های پایدار خود، آن‌ها را به هسته‌های Mainline جدید به‌روزرسانی می‌کند؛ بنابراین در این توزیع، sudo dnf upgrade --refresh به همراه یک reboot تمام کاری است که باید انجام دهید و معمولاً اولین جایی است که یک کاربر می‌تواند هسته جدید را امتحان کند. این زمان‌بندی بخشی از انتخابی است که هنگام اجرای Fedora Server روی یک VPS انجام می‌دهید.

Ubuntu با هر انتشار شش‌ماهه، یک هسته جدید ارائه می‌دهد و سپس آن را از طریق پشته HWE (Hardware Enablement) به نسخه پشتیبانی بلندمدت (LTS) قبلی منتقل می‌کند. تا اوت 2026، نسخه Ubuntu 24.04 LTS همچنان از هسته 6.8 (منتشر شده در آوریل 2024) به عنوان هسته GA استفاده می‌کند، در حالی که پشته HWE آن در اوت 2025 به 6.14 و در فوریه 2026 به 6.17 ارتقا یافته است. این یک مقیاس زمانی واقع‌بینانه است: یک نسخه Mainline از اوت 2026، حدود یک سال بعد به پشته LTS HWE می‌رسد.

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

Debian stable برای کل طول عمر یک نسخه، هسته را ثابت نگه می‌دارد و نسخه‌های جدیدتر را از طریق 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

پس از انجام هر یک از این مراحل، سیستم را reboot کرده و با uname -r و دستور grep که در بالا ذکر شد، وضعیت را تأیید کنید. هسته جدید به‌صورت live-loadable نیست: وصله زدن زنده هسته روی VPS فقط کد توابع خاصی را در هسته در حال اجرا جایگزین می‌کند و نمی‌تواند ساختارها (structure layouts) را تغییر دهد یا فایل‌های debugfs اضافه کند. زمان‌بندی آگاه از کش (Cache aware scheduling) هر دو کار را انجام می‌دهد، زیرا فیلدهایی را به mm_struct اضافه می‌کند؛ بنابراین این قابلیت تنها با بوت کردن یک هسته جدید در دسترس قرار می‌گیرد.

دو نکته عملی برای پیگیری وجود دارد. هسته قدیمی را تا زمانی که هسته جدید برای مدتی بار کاری شما را بدون مشکل تحمل کند، قابل بوت نگه دارید؛ این همان کاری است که تعیین هسته بوت در VPS برای آن انجام می‌شود. همچنین /boot را زیر نظر داشته باشید، زیرا پارتیشن بوت کوچک در VPS پس از چند بار ارتقای هسته پر می‌شود، که در پاک‌سازی هسته‌های قدیمی در Ubuntu به آن پرداخته شده است.

یک نکته واقع‌بینانه دیگر درباره مالکیت: در یک KVM VPS، هسته guest متعلق به شماست: شما آن را انتخاب می‌کنید، بوت می‌کنید و در صورت بروز مشکل به نسخه قبل برمی‌گردانید. هسته host متعلق به ارائه‌دهنده شماست و هیچ تنظیمی در داخل guest شما نمی‌تواند زمان‌بندی (scheduler) هایپروایزر را تغییر دهد. بنابراین، یادداشت‌های انتشار درباره نحوه زمان‌بندی فقط نیمی از ماجرا برای یک کاربر است و نیمه‌ای که شما کنترل می‌کنید، سمت guest است.

منابع استفاده‌شده برای این صفحه

• خلاصه تغییرات نسخه 7.2 در kernelnewbies.org، برای تاریخ انتشار 16 اوت 2026 و تغییرات غیرمرتبط با زمان‌بند (scheduler).
• پوشش خبری LWN درباره سری زمان‌بندی آگاه از کش (cache aware scheduling) در lwn.net/Articles/1041668 و lwn.net/Articles/1058288، برای پارامترهای قابل تنظیم در debugfs، مکانیزم اولویت‌بندی هر پردازش و ارقام بنچمارک گزارش‌شده.
• پچ مربوط به محدودسازی این قابلیت بر اساس توپولوژی، با عنوان "sched/cache: Introduce sched_cache_present"، برای این قاعده که متعادل‌سازی بار آگاه از کش، نیازمند بیش از یک LLC در یک گره NUMA است.

برای نسخه پیشین، به تغییرات هسته لینوکس 7.1 مراجعه کنید. برای آگاهی از نحوه رسیدن به این شماره‌گذاری نسخه‌ها، گاه‌شمار تاریخچه هسته لینوکس را ببینید.

FAQ

آیا زمان‌بندی آگاه از کش (cache aware scheduling) در لینوکس 7.2 باعث افزایش سرعت VPS می‌شود؟

معمولاً به‌تنهایی خیر. این قابلیت تنها زمانی فعال می‌شود که یک گره NUMA بیش از یک کش سطح آخر (last level cache) گزارش دهد، اما در یک guest معمولی KVM چنین ساختاری نمایش داده نمی‌شود، بنابراین کد مربوطه هرگز اجرا نمی‌شود. در مواردی هم که فعال شود، guest همچنان دو بار زمان‌بندی می‌شود: هستهٔ شما یک vCPU را انتخاب می‌کند و هستهٔ میزبان (host) تصمیم می‌گیرد که آن ترد vCPU روی کدام هستهٔ فیزیکی اجرا شود؛ بنابراین تصمیم کش در سمت guest می‌تواند توسط میزبان لغو شود. دستور cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u را در guest خود اجرا کنید. اگر یک خط خروجی برای تمام 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_* را لیست می‌کند.

چگونه زمان‌بندی آگاه از کش را بدون reboot کردن خاموش کنم؟

مقدار 0 را در تنظیم tolerance بنویسید: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. این کار قابلیت را در زمان اجرا غیرفعال می‌کند و یک سوئیچ A/B تمیز برای بنچمارک فراهم می‌آورد. ابتدا مقدار فعلی را با sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance بخوانید و پس از اتمام کار دوباره آن را بازگردانید، زیرا مقادیر پیش‌فرض در بیلد‌های مختلف متفاوت است. هیچ تغییری در debugfs پس از reboot باقی نمی‌ماند. اگر cat مقدار No such file or directory را گزارش کرد، یعنی هستهٔ شما این قابلیت را در خود ندارد و چیزی برای خاموش کردن وجود ندارد.

اوبونتو یا دبیان چه زمانی هسته مبتنی بر 7.2 را عرضه می‌کنند؟

فدورا نسخه‌های پایدار خود را بر اساس هسته‌های جدید mainline بازسازی می‌کند، بنابراین این هسته ابتدا از طریق یک dnf upgrade معمولی و یک reboot در آنجا در دسترس قرار می‌گیرد. اوبونتو با هر انتشار شش‌ماهه، هسته‌های جدیدی ارائه می‌دهد و آن‌ها را از طریق پشتهٔ HWE به نسخهٔ LTS قبلی منتقل می‌کند؛ فاصلهٔ زمانی تاریخی در این مورد نزدیک به یک سال است: تا اوت 2026، پشتهٔ HWE برای 24.04 LTS روی نسخه 6.17 (مربوط به فوریه 2026) قرار دارد، در حالی که هسته GA آن همچنان 6.8 است. دبیان پایدار، یک هسته را برای هر نسخه نگه می‌دارد و نسخه‌های جدیدتر را از طریق trixie-backports ارائه می‌دهد که می‌توانید آن‌ها را به‌صورت پکیج با apt install -t trixie-backports linux-image-amd64 نصب کنید.