Sau khi bộ nhớ Folios không tạo được vào Linux 5.15, sự thay đổi cấp thấp này đối với mã quản lý bộ nhớ nhân có thể có các tác động về hiệu suất đang tìm cách hạ cánh cho Linux 5.16.
Trước cửa sổ hợp nhất Linux 5.16 có thể mở ngay trong ngày mai, Matthew Wilcox đã gửi yêu cầu kéo của mình về việc giới thiệu folios cho hạt nhân. Đây là đoạn trích chính từ yêu cầu kéo dành cho những người không quen thuộc với folios hoặc đã quên các chi tiết mà tính năng này đã hoạt động trong nhiều tháng:
Điểm của tất cả sự kiện này là để cho phép các hệ thống tệp và bộ đệm ẩn của trang quản lý bộ nhớ ở phần lớn hơn PAGE_SIZE. Kế hoạch ban đầu là sử dụng các trang ghép như THP, nhưng tôi đã gặp phải vấn đề với một số chức năng chỉ mong đợi một trang đầu trong khi những người khác mong đợi trang chính xác chứa một byte cụ thể. Loại folio cho phép một hàm khai báo rằng nó chỉ mong đợi một trang đầu. Gần như ngẫu nhiên, điều này cho phép chúng tôi loại bỏ các lệnh gọi khác nhau đến VM_BUG_ON (PageTail (trang)) và compound_head ().
Yêu cầu kéo này chỉ chuyển đổi các phần của MM cốt lõi và bộ nhớ cache của trang. Đối với 5.17, chúng tôi dự định chuyển đổi các hệ thống tệp khác nhau (XFS và AFS đã sẵn sàng; các hệ thống tệp khác có thể tạo ra nó) và cũng chuyển đổi nhiều MM và bộ nhớ cache trang thành folios. Đối với phiên bản 5.18, các trang foos nhiều trang đã sẵn sàng.
Các foos nhiều trang cung cấp một số cải tiến đối với một số khối lượng công việc. Tỷ lệ thắng 80% là có thật, nhưng dường như là một điểm chuẩn nhân tạo (khởi động postgres, không phải là một khối lượng công việc nghiêm trọng). Các khối lượng công việc thực (ví dụ: xây dựng hạt nhân, chạy các postgres ở trạng thái ổn định, v.v.) dường như được hưởng lợi từ 0-10%. Tôi chưa nghe nói về bất kỳ tổn thất hiệu suất nào do kết quả của loạt bài này. Không ai đã thực hiện bất kỳ điều chỉnh hiệu suất nghiêm túc; Tôi tưởng tượng rằng việc điều chỉnh thuật toán readahead có thể mang lại một số chiến thắng thú vị hơn. Cũng có những nơi khác mà chúng tôi có thể chọn để tạo các tán lá lớn nhưng hiện tại thì không, chẳng hạn như các bài viết lớn hơn PAGE_SIZE.
Đối với người dùng cuối, điều đó có nghĩa là lợi ích về hiệu suất có thể có và hơn thế nữa kernel thành công sẽ giải phóng chức năng xung quanh các foos bộ nhớ sẽ được xây dựng.
Xem yêu cầu kéo để biết thêm chi tiết. Bây giờ để xem liệu Linus Torvalds có quyết định kéo ~ hơn 2 nghìn dòng thay đổi này hay không hoặc có bất kỳ phản đối mới/mới nào khác được nêu ra đối với việc bổ sung hay không.
