Linux kernel 7.2 có gì mới cho VPS?

Có gì mới trong Linux kernel 7.2

Linux kernel 7.2 được phát hành vào ngày 16 August 2026. Thay đổi đáng chú ý là cơ chế lập lịch nhận biết cache, được xây dựng phía sau tùy chọn mới CONFIG_SCHED_CACHE. Scheduler hiện cố gắng giữ các thread của cùng một process trên những CPU dùng chung một last level cache (LLC). Những thay đổi khác trong bản phát hành này không làm thay đổi cách workload của bạn được đặt trên CPU.

Tóm tắt phần còn lại của 7.2: viết lại fast commit path của ext4, cải thiện MGLRU (mã reclaim memory theo nguyên tắc least recently used đa thế hệ), thêm device mapper target dm-inlinecrypt cho inline block device encryption, và loại bỏ lần gọi strncpy() cuối cùng khỏi kernel source.

Một yếu tố quyết định tính năng chính có thể mang lại lợi ích cho bạn hay không, nên được nói trước. Cache aware load balancing chỉ được kích hoạt khi một NUMA (non-uniform memory access) node chứa nhiều hơn một LLC. VPS guest thường không được hiển thị bố cục đó. Vì vậy, trên hầu hết guest, code được compile vào kernel nhưng không bao giờ hoạt động. Bạn có thể kiểm tra việc này bằng 2 lệnh trong phần "VPS guest có thấy được tính năng này không" bên dưới.

Mọi nhận định kỹ thuật trên trang này đều dựa trên changelog của 7.2 và chính patch series về cache aware scheduling, được đọc vào ngày 18 August 2026. Các nguồn được liệt kê gần cuối trang để bạn đối chiếu với hành vi của kernel đang chạy trên hệ thống của mình.

Vì sao scheduler cần biết về cache

Một socket hiện đại không chỉ có một last-level cache. Một package AMD EPYC được tạo từ nhiều core complex, và mỗi complex có L3 riêng. Các dòng Intel Xeon gần đây cũng chia một socket thành nhiều cache domain. Vì vậy, một NUMA node có thể chứa bốn, tám hoặc nhiều LLC riêng biệt, và hai thread của cùng một chương trình có thể nằm trên hai LLC khác nhau.

Cách phân bố đó làm tốn thời gian. Khi hai thread dùng chung một page nhưng nằm trên các LLC khác nhau, mỗi cache giữ một bản sao của cache line. Ghi ở một bên sẽ invalidate bản sao ở bên kia, nên lần đọc tiếp theo phải đi qua interconnect hoặc truy cập main memory. Đây là hiện tượng cache bouncing. Nó xuất hiện dưới dạng số cycle phải chờ, không phải thời gian CPU idle. Vì vậy, rất dễ bỏ sót khi bạn chỉ theo dõi load average.

Trước 7.2, load balancer đặt task dựa trên load, mức sử dụng và số CPU idle. Nó không có thông tin cho biết "hai task này đọc cùng một vùng memory". 7.2 bổ sung thông tin đó bằng một phép xấp xỉ gần như không tốn chi phí tính toán: các thread của một process dùng chung một address space, nên được xem là có khả năng dùng chung data.

Cách kernel chọn LLC ưu tiên

Thông tin theo dõi được gắn với process trong mm_struct, cấu trúc kernel đại diện cho một không gian địa chỉ. Kernel định kỳ lấy mẫu vị trí chạy của các thread trong process đó và đếm, theo từng LLC, có bao nhiêu phần của process đang nằm trong mỗi LLC. LLC chứa phần lớn nhất sẽ trở thành LLC ưu tiên của toàn bộ process. Các quyết định sau đó chỉ đọc giá trị này.

Có 2 đường xử lý sử dụng giá trị này. Khi wakeup, scheduler ưu tiên chọn CPU thuộc LLC ưu tiên của process thay vì chọn bất kỳ CPU nào đang idle trong node. Trong quá trình load balancing, khi phải di chuyển task giữa các scheduler group, kernel ưu tiên di chuyển các task vốn đã ưu tiên LLC đích và tránh kéo task rời khỏi LLC mà task đó ưu tiên.

Các giới hạn bảo vệ quan trọng không kém bản thân tính năng, vì gom mọi thread của một process bận vào cùng một cache domain có thể khiến domain đó quá tải trong khi phần còn lại của socket vẫn idle. Các tunable nằm trong debugfs, filesystem debug của kernel, tại /sys/kernel/debug/sched/:

• llc_aggr_tolerance, giá trị từ 0 đến 100, xác định mức độ kernel thực hiện việc gom nhóm. 0 tắt cache aware scheduling trong runtime. 1 là thiết lập thận trọng: process có RSS (resident set size, tức bộ nhớ resident) lớn hơn LLC, hoặc chạy nhiều thread hơn số core của LLC, sẽ được giữ nguyên vị trí. 100 thực hiện gom nhóm bất kể kích thước hoặc số lượng thread.
• llc_overload_pct, mặc định là 50, là mức utilization trung bình mà từ đó LLC ưu tiên được xem là bận.
• llc_imb_pct, mặc định là 20, giới hạn mức mất cân bằng mà một lần migration để gom nhóm có thể tạo ra sau khi LLC ưu tiên vượt ngưỡng quá tải đó.
• llc_epoch_period, mặc định là 10 ms, là khoảng thời gian giữa các lần thu thập occupancy.
• llc_epoch_affinity_timeout, mặc định là 50 ms, là khoảng thời gian một process inactive vẫn giữ preference trước khi kernel xóa preference đó.

Hãy đọc các giá trị hiện tại trước khi thay đổi, vì distribution có thể phát hành với các giá trị mặc định khác: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Những workload nào có thể được lợi, và những workload nào thì không

Các con số dưới đây là số liệu được công bố cùng loạt patch, đo trên phần cứng cấp server; một số phép đo dùng tolerance knob ở mức khá cao. Hãy xem đây là kịch bản tốt trên bare metal, không phải cam kết cho máy của bạn.

[
  {
    "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 với một group duy nhất tăng 30.57%, còn bài test throughput ChaCha20 trên AMD Genoa tăng 44%. Toàn bộ 3 kết quả được đo trên phần cứng server có nhiều LLC, do tester kiểm soát từ đầu đến cuối.

Một workload có khả năng được lợi thường có các đặc điểm sau:

• Có nhiều hơn một thread trong cùng một process, để có các thread cần gom nhóm.
• Các thread thực sự chia sẻ dữ liệu, nên chi phí do cache line bị chuyển qua lại là chi phí thực tế.
• Working set nằm gọn trong một LLC, vì process lớn hơn cache không thể có locality trong cache chỉ bằng cách di chuyển nó.
• Máy còn capacity dự phòng, để scheduler thực sự có lựa chọn về nơi đặt thread tiếp theo.

Các trường hợp không có lợi ích đáng kể:

• Máy đã đầy tải. Mọi CPU đều bận, nên việc placement là bắt buộc và mức cải thiện được báo cáo sẽ giảm.
• Process single-threaded và các pool process độc lập không chia sẻ dữ liệu.
• Working set lớn hơn nhiều so với LLC, trường hợp mà thiết lập llc_aggr_tolerance thận trọng sẽ chủ động bỏ qua.
• Node chỉ báo cáo một LLC; khi đó feature này hoàn toàn không được bật.

Tính năng này cũng có chi phí, và loạt patch đã nói rõ điều đó. Việc thu thập occupancy được thực hiện trong context của task, và một số lần chạy cho thấy request latency tăng vì công việc này làm task chậm quay lại user space. Việc aggregation cũng có thể làm tăng độ biến thiên latency ngay cả khi throughput trung bình tăng. Nếu bạn quan tâm đến tail latency thay vì giá trị trung bình, hãy đo tail latency trên hệ thống của mình.

Guest VPS có thấy được những thông tin này không

Hai yếu tố quyết định câu trả lời.

Thứ nhất, tính năng này phụ thuộc vào topology. Cache aware load balancing chỉ được bật khi trong một NUMA node có nhiều hơn một LLC, và kernel ghi nhận điều đó trong quá trình thiết lập topology. Nếu một node chỉ báo có một LLC, đường xử lý cache aware vẫn không hoạt động, bất kể các tunable được đặt thế nào.

Thứ hai, cache topology mà guest đọc được không phải là topology của host. Đó là topology do CPU model của hypervisor cung cấp. Guest KVM (kernel based virtual machine) mặc định thường không được nhận layout L3 thực của host, nên guest chỉ xử lý dựa trên một mô hình đơn giản hóa.

Kiểm tra những gì guest của bạn nhìn thấy:

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

index3 là L3 cache trên hầu hết CPU x86. Nếu một dòng liệt kê tất cả vCPU, guest thấy một LLC duy nhất, nên tính năng không có gì để sắp xếp. No such file or directory nghĩa là guest hoàn toàn không được expose L3, sau đó guest sẽ coi một cache level thấp hơn là last-level cache. Các ranh giới này do hypervisor tạo ra, không phải ranh giới thực của silicon.

Tiếp theo là double scheduling. Đây là điểm cần nói rõ với mọi tenant. Kernel của guest đặt các thread lên vCPU. Kernel của host đặt các thread vCPU đó lên các physical core. Guest có thể chủ động gom bốn thread vào vCPU 0 đến 3, nhưng thực chất chỉ đang đưa ra ưu tiên cho bốn thread trên host. Host vẫn có thể đặt chúng vào các physical cache domain khác nhau và di chuyển chúng sau đó. Quyết định của guest không sai, nhưng đó không phải quyết định cuối cùng. Đây cũng là ranh giới giữa các layer tạo ra steal time mà noisy neighbour gây ra trên các vCPU của bạn.

Vậy tính năng này tác động đến tenant VPS ở đâu? Có hai nơi. Với các plan có topology thực thay vì topology tổng hợp, chẳng hạn dedicated core hoặc instance lớn được pass-through layout, guest scheduler đang đưa ra quyết định dựa trên phần cứng thực tế. Ngoài ra, trên kernel của host do provider quản lý, việc cache aware placement cho các thread vCPU của bạn là lợi ích mà provider có thể tận dụng, không phải bạn. Cache layout cũng khác nhau tùy architecture. Đây là thêm một biến số khi bạn so sánh VPS Arm với VPS x86.

Đo cache behavior bên trong guest khó hơn trên máy vật lý. perf stat -e cache-misses thường báo <not supported> vì hypervisor không expose PMU (performance monitoring unit) cho guest. Thay vào đó, hãy đo throughput và latency của chính ứng dụng, rồi dùng debugfs knob làm công tắc giữa hai lần chạy.

Kiểm tra kernel có CONFIG_SCHED_CACHE hay không

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 có nghĩa là kernel được build với tùy chọn này. Dòng có nội dung # CONFIG_SCHED_CACHE is not set có nghĩa là tùy chọn tồn tại trong phiên bản đó nhưng distribution đã tắt nó. Nếu hoàn toàn không có output thì thường là kernel cũ hơn tùy chọn này; uname -r sẽ xác nhận điều đó. Một số cloud image tối giản không có file /boot/config-*. Trong trường hợp đó, hãy đọc zcat /proc/config.gz thay thế. Cách này chỉ hoạt động khi kernel được build với CONFIG_IKCONFIG_PROC.

Dòng ls sẽ in các tunable llc_* khi feature đã được compile vào kernel. Nếu lệnh không in gì dù CONFIG_SCHED_CACHE=y, trước tiên hãy mount debugfs bằng sudo mount -t debugfs none /sys/kernel/debug.

Để so sánh workload khi bật và tắt feature, trước tiên hãy ghi lại giá trị hiện tại vì bạn phải khôi phục lại giá trị đó:

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

Chạy benchmark, ghi lại giá trị đã lưu rồi ghi giá trị đó trở lại và chạy benchmark lần nữa. Các thay đổi ghi qua debugfs không tồn tại sau khi reboot. Đây là hành vi cần có trong quá trình testing.

Khi nào kernel của distribution sẽ có 7.2

Mainline không phải kernel mà VPS của bạn boot. Phiên bản trong uname -r đến từ distribution của bạn, và mỗi distribution có lộ trình riêng để đưa một bản phát hành mainline lên server của bạn.

Fedora rebase các bản stable lên kernel mainline mới trong thời gian chúng còn được support. Vì vậy, tại Fedora, chỉ cần sudo dnf upgrade --refresh rồi reboot là hoàn tất. Đây thường là nơi đầu tiên tenant có thể thử kernel mới. Nhịp phát hành đó là một phần của lựa chọn khi bạn chạy Fedora Server trên VPS.

Ubuntu phát hành kernel mới cùng mỗi bản release cách nhau 6 tháng, sau đó đưa kernel đó về bản release long term support (LTS) trước đó thông qua stack HWE (hardware enablement). Tính đến tháng 8 năm 2026, Ubuntu 24.04 LTS vẫn cài 6.8 từ tháng 4 năm 2024 làm kernel GA, trong khi stack HWE đã chuyển lên 6.14 vào tháng 8 năm 2025 và lên 6.17 vào tháng 2 năm 2026. Đây là mốc thời gian thực tế: một bản mainline phát hành vào tháng 8 năm 2026 sẽ vào stack HWE của LTS khoảng 1 năm sau.

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

Debian stable giữ một kernel trong suốt vòng đời của bản release và cung cấp kernel mới hơn thông qua backports. Bạn opt in theo từng package:

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

Sau mỗi cách trên, hãy reboot rồi xác nhận bằng uname -r và grep ở trên. Kernel mới không thể được load trực tiếp khi hệ thống đang chạy: live kernel patching trên VPS thay thế code của từng function trong kernel đang chạy, nhưng không thể thay đổi layout của structure hoặc thêm file debugfs. Cache aware scheduling thực hiện cả 2 việc đó vì nó thêm các field vào mm_struct. Vì vậy, tính năng này chỉ xuất hiện sau khi boot kernel mới.

Có 2 việc thực tế cần làm tiếp theo. Giữ kernel cũ ở trạng thái có thể boot cho đến khi kernel mới đã chạy tải của bạn đủ lâu. Đây là mục đích của ghim kernel được boot trên VPS. Đồng thời, hãy theo dõi /boot vì phân vùng boot nhỏ trên VPS có thể đầy sau vài lần upgrade kernel, như đã đề cập trong dọn kernel cũ trên Ubuntu.

Cuối cùng, cần hiểu rõ quyền sở hữu. Trên KVM VPS, guest kernel thuộc quyền kiểm soát của bạn: bạn chọn kernel, boot kernel và rollback kernel. Host kernel thuộc về provider, và không setting nào bên trong guest có thể thay đổi scheduler mà hypervisor chạy. Vì vậy, release note về scheduler placement chỉ là một nửa câu chuyện đối với tenant. Nửa mà bạn kiểm soát là phía guest.

Nguồn được sử dụng cho trang này

• Bản tóm tắt changelog 7.2 trên kernelnewbies.org, dùng cho ngày phát hành 16 August 2026 và các thay đổi không liên quan đến scheduler.
• Bài tổng hợp của LWN về loạt thay đổi cache aware scheduling tại lwn.net/Articles/1041668 và lwn.net/Articles/1058288, dùng cho các tunable trong debugfs, cơ chế tùy chọn theo từng process và các số liệu benchmark được báo cáo.
• Patch giới hạn tính năng theo topology, "sched/cache: Introduce sched_cache_present", dùng cho quy tắc rằng cache aware load balancing cần nhiều hơn một LLC trong một NUMA node.

Để xem bản phát hành trước, hãy xem những thay đổi trong Linux kernel 7.1. Để biết các số phiên bản được hình thành như thế nào, hãy xem timeline lịch sử Linux kernel.

FAQ

Tính năng lập lịch nhận biết cache trong Linux 7.2 có làm VPS nhanh hơn không?

Thường là không, nếu chỉ bật tính năng này. Tính năng chỉ được kích hoạt khi một NUMA node báo cáo có nhiều hơn một last level cache. Guest KVM thông thường không hiển thị bố cục đó, nên code không bao giờ được thực thi. Khi tính năng được kích hoạt, guest vẫn được lập lịch 2 lần: kernel của bạn chọn một vCPU, còn kernel của host quyết định thread của vCPU đó chạy trên physical core nào. Vì vậy, quyết định về cache ở phía guest có thể bị host vô hiệu hóa. Chạy cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u trong guest. Nếu một dòng bao phủ mọi vCPU, tính năng không có gì để sắp xếp.

Làm cách nào kiểm tra kernel có CONFIG_SCHED_CACHE?

Chạy grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y nghĩa là tính năng đã được build sẵn, # CONFIG_SCHED_CACHE is not set nghĩa là distribution đã tắt tính năng này, còn không có output nghĩa là kernel cũ hơn option này. Nếu image không có file /boot/config-*, hãy thử zcat /proc/config.gz. File này chỉ tồn tại trên các kernel được build với CONFIG_IKCONFIG_PROC. Bạn có thể xác nhận lúc runtime bằng sudo ls /sys/kernel/debug/sched/ | grep -i llc. Lệnh này liệt kê các tunable llc_* khi tính năng hiện diện.

Làm cách nào tắt lập lịch nhận biết cache mà không reboot?

Ghi 0 vào tolerance knob bằng lệnh: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Thao tác này tắt tính năng tại runtime, phù hợp để làm công tắc A/B sạch cho benchmark. Đọc giá trị hiện tại trước bằng sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance rồi ghi lại sau đó, vì giá trị mặc định khác nhau giữa các build. Không có nội dung nào ghi vào debugfs được giữ lại sau khi reboot. Nếu cat báo No such file or directory, kernel của bạn không được build kèm tính năng này và không có gì để tắt.

Khi nào Ubuntu hoặc Debian sẽ phát hành kernel dựa trên 7.2?

Fedora rebase các bản stable lên kernel mainline mới, nên tính năng này sẽ xuất hiện ở đó trước thông qua một dnf upgrade bình thường và một lần reboot. Ubuntu phát hành kernel mới cùng mỗi bản release cách nhau 6 tháng và đưa chúng về LTS trước đó thông qua HWE stack. Khoảng cách theo lịch sử gần 1 năm: tính đến tháng 8 năm 2026, HWE stack của Ubuntu 24.04 LTS đang dùng 6.17 từ tháng 2 năm 2026, trong khi GA kernel vẫn là 6.8. Debian stable giữ một kernel cho mỗi bản release và cung cấp kernel mới hơn thông qua trixie-backports. Bạn cài kernel này theo package bằng apt install -t trixie-backports linux-image-amd64.