2012-07-18 28 views

Trả lời

27

Kích thước trang mặc định được cố định bởi những gì MMU (bộ quản lý bộ nhớ) của CPU hỗ trợ. Trong 32-bit bảo vệ chế độ x86 hỗ trợ hai loại trang:

  • người bình thường, 4 KiB
  • người lớn, 4 MiB

Không phải tất cả các bộ xử lý x86 hỗ trợ các trang lớn. Một cần phải có một CPU với khả năng mở rộng kích thước trang (PSE). Điều này loại trừ các bộ xử lý trước Pentium. Hầu như tất cả các CPU x86 thế hệ hiện tại thực hiện nó.

4 KiB phổ biến rộng rãi trang chi tiết trong các kiến ​​trúc khác. Người ta có thể cho rằng kích thước này xuất phát từ việc phân chia địa chỉ virut 32 bit thành hai chỉ mục 10 bit trong các thư mục/bảng trang và 12 bit còn lại cho kích thước trang 4 KiB.

+0

Chuông 4M chỉ dành cho chế độ 32 bit x86. 64-bit x86 sử dụng các ôm 2M hoặc 1G, vì định dạng trang bảng 4 cấp sử dụng 9 bit cho mỗi cấp độ. https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared-with-the. (Kích thước trang không lớn vẫn là 4k ở chế độ dài, vì vậy bộ đệm L1DTLB và L1D vẫn có thể hoạt động giống nhau, trong số các lý do khác.) –

+0

@PeterCordes, cảm ơn bạn đã bình luận của bạn. Tôi đã thực sự giải quyết các chế độ 32-bit chỉ và đó là những gì tôi thường biểu thị bằng x86. –

12

That depends on the processor architecture.

Kích thước trang mặc định là 4 KB trên nhiều kiến ​​trúc. Nó thường có thể được tăng lên (đôi khi rất nhiều, chẳng hạn như 1GB của AMD64) bằng cách chuyển sang chế độ huge page. Điều này cho phép bảng trang nhỏ hơn, điều này có thể dẫn đến cải thiện hiệu suất.

17

Thiết kế của 4KB kích thước trang bình thường của kiến ​​trúc 32-bit thực sự là rất thú vị :)

Và tôi muốn thêm một câu trả lời thêm để chứng minh tại sao nó là hợp lý.

x86 sử dụng '2-pass' để dịch địa chỉ bộ nhớ ảo thành địa chỉ bộ nhớ vật lý.

Giả sử cả thư mục trang và bảng trang chứa mục nhập enter image description here và kích thước trang là enter image description here byte. Để tận dụng tối đa địa chỉ enter image description here, ta có:

enter image description here

Mỗi mục trong thư mục trang/table tiêu thụ 4 bytes (32-bit), do đó:

enter image description here

Do đó y = 12 và kích thước trang tính theo byte sẽ là enter image description here = enter image description here = 4KB.


Và còn '1-pass' thì sao? Điều này là thú vị bởi vì một cách logic, chúng ta có thể sử dụng một bảng trang đơn để tra cứu địa chỉ.

Giả sử rằng thư mục trang chứa các mục nhập enter image description here, mỗi mục ánh xạ địa chỉ đến trang tương ứng và kích thước trang là enter image description here byte.

Một lần nữa, để tận dụng tối đa enter image description here địa chỉ, chúng ta cần:

enter image description here

Và:

enter image description here

Chúng tôi nhận được y = 17, và kích thước trang là enter image description here = enter image description here = 128KB.

Dù sao, công việc này "hợp lý". Nếu chúng tôi giới thiệu TLB, kích thước bộ nhớ lớn như vậy sẽ là một di chuyển: các trang bộ nhớ sẽ khó để phù hợp với TLB và thiết kế sẽ không hiệu quả.


Chúng tôi cũng có thể cho rằng, trong phiên bản '2-pass', thư mục trang và bảng trang có thể có các kích thước khác nhau. Tuy nhiên, điều này có nghĩa là chúng tôi sẽ sử dụng thư mục trang lớn hơn, sẽ chiếm nhiều hơn một trang bộ nhớ. Đáng buồn thay, mỗi khi một quá trình người dùng mới được sinh ra, cho thư mục trang của riêng nó, hệ điều hành phải phân bổ các trang kế tiếp, không được thiết kế thanh lịch.

+0

Thuật ngữ thông thường là "bảng trang 2 cấp", không phải "2 lần". ví dụ. [x86-64 sử dụng bảng trang 4 cấp] (https://stackoverflow.com/questions/46509152/why-in-64bit-the-virtual-address-are-4-bits-short-48bit-long-compared -with-the) (vẫn với 4k trang thông thường, nhưng hugepages là 2M hoặc 1G thay vì 4M.) –

+0

Phần bảng trang 1 cấp của bạn tạo ra một giả thiết không cần thiết: Bản thân trang bảng không * có * thành 1 trang trong kích thước. Bạn có thể có các trang nhỏ hơn (và một bảng trang phẳng lớn hơn nữa).Những gì hút khoảng 1 cấp là kích thước bảng trang: một quá trình chỉ với một lượng nhỏ bộ nhớ được ánh xạ có thể có một cây thưa thớt chỉ với một vài bảng trang cấp dưới cùng. TLB không phải là vấn đề gì cả; mỗi TLB chứa bản dịch đầy đủ từ tất cả các cấp của bảng trang, vì vậy các trang lớn hơn có nghĩa là các bit trang ít hơn, có nghĩa là một CAM nhỏ hơn. Và ít hơn các mục TLB bao gồm nhiều bộ nhớ hơn. –

0

Tôi thêm câu trả lời/nhận xét này vì việc tính toán sleepsort rất thú vị, tôi phải thêm nó vào trang web của mình (với việc nhắc đến nguồn của khóa học). Câu trả lời (có thể) cho câu hỏi cách bạn có thể tính toán các trang được lập trình có thể được tìm thấy here. Cách nó được tính toán như đã đề cập bởi sleepsort là rất thú vị. Tôi đã làm tương tự cho x86_64 và kết quả không phải là những gì tôi mong đợi. Tuy nhiên đọc thêm trên memory management x86_64 Tôi thấy rằng đối với 64 bit intel, 16 bit không được sử dụng, để lại nó 48 bit để chúng tôi tính toán. 9 bit cho cành cây bộ nhớ, mỗi nhánh khác 9 bit, tại đây trong 9 số khác cho các chi nhánh và cuối cùng là 9 bit cho lá của cành cuối cùng. Vì vậy, 48 - 36 = 12 bit cho mỗi địa chỉ trong trang bộ nhớ. 2^12 = 4096 như đã đề cập trước đó bởi sleepsort. Tôi chỉ tự hỏi có bao nhiêu đường chuyền kiến ​​trúc này là, 3 hoặc 4 (nếu có ai có thể giải thích đó) sau tính sleepsort của:

2^x * 2^x * 2^x * 2^x * 2^y = 2^48 
4x + y = 48 

this time we have 8 bytes for each address (8 bytes * 8 bits/byte = 64 bits) 

2^y/2^3 = 2^x 
y - 3 = x 
filled in in previous equation: 

4(y - 3) + y = 48 
4y - 12 + y = 48 
5y = 60 
y = 12 
because 2^y represents the pagesize, the size = 2^12 = 4096 bytes 

Để lại tôi với câu hỏi "những gì về những trang lớn trong Linux"?

Các vấn đề liên quan