Tại sao (không) phân khúc?

Tôi đang nghiên cứu các hệ điều hành và kiến ​​trúc x86, và trong khi tôi đang đọc về phân đoạn và phân trang, tôi tự nhiên tò mò về cách các hệ điều hành hiện đại xử lý việc quản lý bộ nhớ. Từ những gì tôi tìm thấy Linux và hầu hết các hệ điều hành khác về cơ bản tránh xa phân khúc có lợi cho việc phân trang. Một vài lý do cho điều này mà tôi tìm thấy là sự đơn giản và tính di động.

Những ứng dụng thực tế nào dành cho phân khúc (x86 hay nói cách khác) và chúng ta sẽ thấy các hệ điều hành mạnh mẽ sử dụng nó hay chúng sẽ tiếp tục ưu tiên một hệ thống phân trang.

Bây giờ tôi biết đây là một câu hỏi được tải nhưng tôi tò mò cách phân khúc sẽ được xử lý với các hệ điều hành mới được phát triển. Liệu nó có ý nghĩa rất nhiều để ủng hộ phân trang mà không ai sẽ xem xét một cách tiếp cận 'phân khúc' hơn? Nếu vậy, tại sao?

Và khi tôi nói phân khúc 'trốn tránh', tôi ngụ ý rằng Linux chỉ sử dụng nó theo như nó phải làm. Chỉ có 4 phân đoạn cho người dùng và mã nhân / phân đoạn dữ liệu. Trong khi đọc tài liệu Intel, tôi có cảm giác rằng phân khúc được thiết kế với các giải pháp mạnh mẽ hơn trong tâm trí. Sau đó, một lần nữa tôi được cho biết rằng x86 có thể phức tạp đến mức nào.

Tôi đã tìm thấy giai thoại thú vị này sau khi được liên kết với 'thông báo' ban đầu của Linux Torvald cho Linux. Ông nói điều này một vài bài viết sau:

Đơn giản, tôi muốn nói rằng porting là không thể. Nó chủ yếu ở C, nhưng hầu hết mọi người sẽ không gọi những gì tôi viết C. Nó sử dụng mọi tính năng có thể hiểu được của 386 tôi có thể tìm thấy, vì đó cũng là một dự án để dạy tôi về 386. Như đã đề cập, nó sử dụng MMU , cho cả phân trang (chưa vào đĩa) và phân đoạn. Đó là phân đoạn làm cho nó thực sự phụ thuộc 386 (mọi tác vụ đều có phân đoạn 64Mb cho mã & dữ liệu - tối đa 64 tác vụ trong 4Gb. Bất kỳ ai cần nhiều hơn 64Mb / tác vụ - cookie khó khăn).

Tôi đoán thử nghiệm của riêng tôi với x86 đã khiến tôi đặt câu hỏi này. Linus không có StackOverflow, vì vậy anh ta chỉ thực hiện nó để dùng thử.

Với phân đoạn, chẳng hạn, có thể đặt từng đối tượng được phân bổ động (malloc) vào phân đoạn bộ nhớ của chính nó. Phần cứng sẽ tự động kiểm tra giới hạn phân khúc và toàn bộ lớp lỗi bảo mật (lỗi tràn bộ đệm) sẽ được loại bỏ.

Ngoài ra, vì tất cả các độ lệch phân đoạn bắt đầu từ 0, tất cả các mã được biên dịch sẽ tự động độc lập với vị trí. Gọi vào một DLL khác sẽ chuyển sang một cuộc gọi xa với độ lệch không đổi (tùy thuộc vào chức năng được gọi). Điều này sẽ đơn giản hóa rất nhiều trình liên kết và bộ tải.

Với 4 vòng bảo vệ, có thể tạo ra kiểm soát truy cập chi tiết hơn (với phân trang bạn chỉ có 2 cấp độ bảo vệ: người dùng và người giám sát) và hạt nhân hệ điều hành mạnh mẽ hơn. Ví dụ, chỉ có vòng 0 có toàn quyền truy cập vào phần cứng. Bằng cách tách các trình điều khiển lõi và trình điều khiển thiết bị lõi thành các vòng 0 và 1, bạn có thể tạo ra một hệ điều hành vi nhân mạnh mẽ hơn và rất nhanh, trong đó hầu hết các kiểm tra truy cập có liên quan sẽ được thực hiện bởi CTNH. (Trình điều khiển thiết bị có thể có quyền truy cập vào phần cứng thông qua bitmap truy cập I / O trong TSS.)

Tuy nhiên .. x86 là một chút hạn chế. Nó chỉ có 4 thanh ghi phân đoạn dữ liệu "miễn phí"; tải lại chúng khá tốn kém và chỉ có thể truy cập đồng thời 8192 phân đoạn. (Giả sử bạn muốn tối đa hóa số lượng đối tượng có thể truy cập, do đó GDT chỉ giữ các mô tả hệ thống và mô tả LDT.)

Bây giờ, với phân đoạn chế độ 64 bit được mô tả là "di sản" và kiểm tra giới hạn phần cứng chỉ được thực hiện trong các trường hợp giới hạn. IMHO, một sai lầm LỚN. Trên thực tế tôi không đổ lỗi cho Intel, tôi chủ yếu đổ lỗi cho các nhà phát triển, phần lớn trong số họ nghĩ rằng phân khúc là "quá phức tạp" và khao khát không gian địa chỉ phẳng. Tôi cũng đổ lỗi cho các nhà văn hệ điều hành thiếu trí tưởng tượng để đưa phân khúc vào sử dụng tốt. (AFAIK, OS / 2 là hệ điều hành duy nhất sử dụng đầy đủ các tính năng phân đoạn.)

Câu trả lời ngắn gọn là phân khúc là một hack, được sử dụng để tạo ra một bộ xử lý có khả năng hạn chế để giải quyết bộ nhớ vượt quá các giới hạn đó.

Trong trường hợp của 8086, có 20 dòng địa chỉ trên chip, có nghĩa là nó có thể truy cập vật lý 1Mb bộ nhớ. Tuy nhiên, kiến ​​trúc bên trong dựa trên địa chỉ 16 bit, có thể là do mong muốn duy trì tính nhất quán với 8080. Vì vậy, tập lệnh bao gồm các thanh ghi phân đoạn sẽ được kết hợp với các chỉ mục 16 bit để cho phép giải quyết toàn bộ bộ nhớ 1Mb . 80286 đã mở rộng mô hình này với MMU thực sự, để hỗ trợ bảo vệ dựa trên phân khúc và giải quyết nhiều bộ nhớ hơn (iirc, 16Mb).

Trong trường hợp của PDP-11, các mô hình bộ xử lý sau này đã cung cấp phân đoạn vào không gian Hướng dẫn và Dữ liệu, một lần nữa để hỗ trợ các giới hạn của không gian địa chỉ 16 bit.

Vấn đề với phân đoạn rất đơn giản: chương trình của bạn phải hoạt động rõ ràng xung quanh các giới hạn của kiến ​​trúc. Trong trường hợp của 8086, điều này có nghĩa là khối bộ nhớ liền kề lớn nhất mà bạn có thể truy cập là 64k. nếu bạn cần truy cập nhiều hơn thế, bạn sẽ phải thay đổi các thanh ghi phân khúc của mình. Điều đó có nghĩa là, đối với một lập trình viên C, bạn phải nói cho trình biên dịch C biết loại con trỏ nào sẽ tạo ra.

Việc lập trình MC68k dễ dàng hơn nhiều, có kiến ​​trúc bên trong 32 bit và không gian địa chỉ vật lý 24 bit.

Đối với 80x86, có 4 tùy chọn - "không có gì", chỉ phân đoạn, chỉ phân trang và cả phân đoạn và phân trang.

Đối với "không có gì" (không phân đoạn hoặc phân trang), bạn sẽ không có cách nào dễ dàng để bảo vệ một quá trình từ chính nó, không có cách dễ dàng để bảo vệ các quy trình với nhau, không có cách nào để xử lý những thứ như phân mảnh không gian địa chỉ vật lý, không có cách nào để tránh vị trí mã độc lập, v.v. Mặc dù tất cả những vấn đề này, về mặt lý thuyết, nó có thể hữu ích trong một số trường hợp (ví dụ: thiết bị nhúng chỉ chạy một ứng dụng hoặc có thể là thứ gì đó sử dụng JIT và ảo hóa mọi thứ).

Chỉ dành cho phân khúc; nó gần như giải quyết vấn đề "bảo vệ một quá trình khỏi chính nó", nhưng phải mất rất nhiều công sức để làm cho nó có thể sử dụng được khi một quá trình muốn sử dụng hơn 8192 phân đoạn (giả sử một LDT cho mỗi quy trình), khiến nó hầu như bị hỏng. Bạn gần như giải quyết vấn đề "bảo vệ các quá trình khỏi nhau"; nhưng các phần mềm khác nhau chạy ở cùng cấp đặc quyền có thể tải / sử dụng các phân đoạn của nhau (có nhiều cách để khắc phục điều đó - sửa đổi các mục GDT trong khi chuyển điều khiển và / hoặc sử dụng LDT). Nó cũng chủ yếu giải quyết vấn đề "mã độc lập vị trí" (nó có thể gây ra vấn đề "mã phụ thuộc phân khúc" nhưng điều đó ít quan trọng hơn nhiều). Nó không làm gì cho vấn đề "phân mảnh không gian địa chỉ vật lý".

Đối với chỉ phân trang; nó không giải quyết được vấn đề "bảo vệ quá trình khỏi chính nó" (nhưng hãy trung thực ở đây, đây thực sự chỉ là vấn đề để gỡ lỗi / kiểm tra mã được viết bằng các ngôn ngữ không an toàn và dù sao cũng có nhiều công cụ mạnh hơn như valgrind). Nó giải quyết hoàn toàn vấn đề "bảo vệ các quá trình khỏi nhau", giải quyết hoàn toàn vấn đề "mã độc lập vị trí" và giải quyết hoàn toàn vấn đề "phân mảnh không gian địa chỉ vật lý". Là một phần thưởng bổ sung, nó mở ra một số kỹ thuật rất mạnh mà không nơi nào thực tế mà không phân trang; bao gồm những thứ như "sao chép ghi", tập tin ánh xạ bộ nhớ, xử lý không gian hoán đổi hiệu quả, v.v.

Bây giờ bạn nghĩ rằng sử dụng cả phân đoạn và phân trang sẽ mang lại cho bạn những lợi ích của cả hai; và về mặt lý thuyết, điều đó có thể, ngoại trừ lợi ích duy nhất bạn có được từ việc phân khúc (điều đó không được thực hiện tốt hơn bằng cách phân trang) là một giải pháp cho vấn đề "bảo vệ một quá trình khỏi chính nó" mà không ai thực sự quan tâm. Trong thực tế những gì bạn nhận được là sự phức tạp của cả hai và chi phí chung của cả hai, vì rất ít lợi ích.

Đây là lý do tại sao hầu hết tất cả các HĐH được thiết kế cho 80x86 đều không sử dụng phân đoạn để quản lý bộ nhớ (chúng sử dụng nó cho những thứ như lưu trữ trên mỗi CPU và mỗi tác vụ, nhưng điều đó chủ yếu chỉ để thuận tiện để tránh sử dụng đăng ký mục đích chung hữu ích hơn cho những điều này nhiều thứ).

Tất nhiên các nhà sản xuất CPU không ngớ ngẩn - họ sẽ không dành thời gian và tiền bạc để tối ưu hóa thứ gì đó mà họ không biết ai sử dụng (họ sẽ tối ưu hóa thứ mà hầu hết mọi người sử dụng thay thế). Vì lý do này, các nhà sản xuất CPU không tối ưu hóa phân khúc, điều này làm cho việc phân đoạn chậm hơn mức có thể, điều này khiến các nhà phát triển hệ điều hành muốn tránh điều đó nhiều hơn. Hầu hết họ chỉ giữ phân khúc cho khả năng tương thích ngược (điều này rất quan trọng).

Cuối cùng, AMD đã thiết kế chế độ dài. Không có mã 64 bit cũ / hiện có để lo lắng, vì vậy (đối với mã 64 bit) AMD đã loại bỏ càng nhiều phân khúc càng tốt. Điều này đã cho các nhà phát triển hệ điều hành một lý do khác (không có cách dễ dàng nào để mã cổng được thiết kế để phân đoạn thành 64 bit) để tiếp tục tránh phân đoạn.

Tôi khá choáng váng vì trong suốt thời gian kể từ khi câu hỏi này được đăng lên mà không ai đề cập đến nguồn gốc của kiến ​​trúc bộ nhớ phân đoạn và sức mạnh thực sự mà họ có thể mua được.

Hệ thống ban đầu được phát minh hoặc tinh chỉnh thành dạng hữu ích, tất cả các tính năng xung quanh thiết kế và sử dụng các hệ thống bộ nhớ ảo phân trang (cùng với hệ thống tập tin đa xử lý và phân cấp đối xứng) là Multics (và cũng xem trang web Multician ). Bộ nhớ được phân đoạn cho phép Multics cung cấp một cái nhìn cho người dùng rằng mọi thứ đều nằm trong bộ nhớ (ảo) và nó cho phép mức độ chia sẻ cuối cùng của mọi thứở dạng trực tiếp (tức là địa chỉ trực tiếp trong bộ nhớ). Hệ thống tập tin trở thành một bản đồ cho tất cả các phân đoạn trong bộ nhớ. Khi được sử dụng đúng cách theo cách có hệ thống (như trong Multics), bộ nhớ được phân đoạn sẽ giải phóng người dùng khỏi nhiều gánh nặng của việc quản lý lưu trữ thứ cấp và chia sẻ dữ liệu cũng như liên lạc giữa các quá trình. Các câu trả lời khác đã đưa ra một số tuyên bố gợn sóng bằng tay rằng bộ nhớ phân đoạn khó sử dụng hơn, nhưng điều này đơn giản là không đúng và Multics đã chứng minh rằng với thành công vang dội từ nhiều thập kỷ trước.

Intel đã tạo ra một phiên bản bộ nhớ phân đoạn 80286, mặc dù nó khá mạnh, nhưng những hạn chế của nó đã ngăn không cho nó được sử dụng cho bất cứ thứ gì thực sự hữu ích. 80386 đã cải thiện những hạn chế này, nhưng các lực lượng thị trường tại thời điểm đó đã ngăn cản rất nhiều sự thành công của bất kỳ hệ thống nào có thể thực sự tận dụng những cải tiến này. Trong những năm kể từ đó, dường như tất cả quá nhiều người đã học cách bỏ qua những bài học trong quá khứ.

Intel cũng đã cố gắng sớm xây dựng một siêu vi có khả năng cao hơn gọi là iAPX 432 , có thể vượt xa mọi thứ khác vào thời điểm đó và nó có kiến ​​trúc bộ nhớ được phân đoạn và các tính năng khác hướng mạnh vào lập trình hướng đối tượng. Việc triển khai ban đầu chỉ là quá chậm và không có nỗ lực nào được thực hiện để khắc phục nó.

Một cuộc thảo luận chi tiết hơn về cách Multics sử dụng phân đoạn và phân trang có thể được tìm thấy trong bộ nhớ Multics Virtual Multics của Paul Green - Hướng dẫn và phản ánh

Phân đoạn là một hack / cách giải quyết để cho phép xử lý tối đa 1 MB bộ nhớ bằng bộ xử lý 16 bit - thông thường chỉ có thể truy cập 64K bộ nhớ.

Khi bộ xử lý 32 bit xuất hiện, bạn có thể xử lý tối đa 4GB bộ nhớ với mô hình bộ nhớ phẳng và không còn nhu cầu phân đoạn nữa - Các thanh ghi phân đoạn đã được lọc lại làm bộ chọn cho GDT / phân trang trong chế độ được bảo vệ (mặc dù bạn có thể có chế độ bảo vệ 16-bit).

Ngoài ra, chế độ bộ nhớ phẳng thuận tiện hơn nhiều cho trình biên dịch - bạn có thể viết các chương trình phân đoạn 16 bit bằng C , nhưng nó hơi cồng kềnh. Một mô hình bộ nhớ phẳng làm cho mọi thứ đơn giản hơn.

Một số kiến ​​trúc (như ARM) hoàn toàn không hỗ trợ các phân đoạn bộ nhớ. Nếu Linux phụ thuộc vào nguồn vào các phân khúc, thì nó không thể được chuyển đến các kiến ​​trúc đó một cách dễ dàng.

Nhìn vào bức tranh rộng hơn, sự thất bại của các phân đoạn bộ nhớ có liên quan đến sự phổ biến liên tục của số học C và con trỏ. C phát triển thực tế hơn trên một kiến ​​trúc với bộ nhớ phẳng; và nếu bạn muốn bộ nhớ phẳng, bạn chọn phân trang bộ nhớ.

Đã có một khoảng thời gian của thập niên 80 khi Intel, với tư cách là một tổ chức, đang dự đoán sự phổ biến trong tương lai của Ada và các ngôn ngữ lập trình cấp cao khác. Về cơ bản, đây là nơi mà một số thất bại ngoạn mục hơn của họ, như phân khúc bộ nhớ APX432 và 286 khủng khiếp, đến từ. Với 386, họ đã đầu tư cho các lập trình viên bộ nhớ phẳng; phân trang và một TLB đã được thêm vào và các phân đoạn được thay đổi kích thước thành 4GB. Và về cơ bản, AMD đã loại bỏ các phân đoạn với x86_64 bằng cách biến reg cơ sở thành không quan tâm / ngụ ý-0 (ngoại trừ fs? Cho TLS tôi nghĩ sao?)

Phải nói rằng, lợi thế của các phân đoạn bộ nhớ là rõ ràng - chuyển đổi không gian địa chỉ mà không cần phải sao lưu TLB. Có thể một ngày nào đó ai đó sẽ tạo ra một CPU cạnh tranh hiệu năng hỗ trợ phân đoạn, chúng ta có thể lập trình HĐH định hướng phân đoạn cho nó và các lập trình viên có thể tạo Ada / Pascal / D / Rust / khác-langage-that-không-yêu cầu phẳng chương trình -memory cho nó.

Phân khúc là một gánh nặng lớn cho các nhà phát triển ứng dụng. Đây là nơi mà sự thúc đẩy lớn đến từ việc làm phân khúc đi.

Thật thú vị, tôi thường tự hỏi i86 có thể tốt hơn bao nhiêu nếu Intel loại bỏ tất cả các hỗ trợ cũ cho các chế độ cũ này. Ở đây tốt hơn sẽ ngụ ý năng lượng thấp hơn và có thể hoạt động nhanh hơn.

Tôi đoán người ta có thể lập luận rằng Intel đã làm sữa với các phân đoạn 16 bit dẫn đến một cuộc nổi dậy của các nhà phát triển. Nhưng hãy đối mặt với nó một không gian địa chỉ 64k không có gì đặc biệt là khi bạn nhìn vào ứng dụng hiện đại. Cuối cùng, họ đã phải làm một cái gì đó bởi vì sự cạnh tranh có thể và đã tiếp thị hiệu quả chống lại các vấn đề không gian địa chỉ của i86.

Phân đoạn dẫn đến dịch và hoán đổi trang chậm hơn

Vì những lý do đó, phân khúc chủ yếu được giảm xuống trên x86-64.

Sự khác biệt chính giữa chúng là:

• phân trang chia bộ nhớ thành các phần có kích thước cố định
• phân khúc cho phép độ rộng khác nhau cho mỗi đoạn

Mặc dù nó có vẻ thông minh hơn khi có độ rộng phân đoạn có thể định cấu hình, khi bạn tăng kích thước bộ nhớ cho một quy trình, việc phân mảnh là không thể tránh khỏi, ví dụ:

|   | process 1 |       | process 2 |                        |
     -----------         -----------
0                                                            max

cuối cùng sẽ trở thành quá trình 1 phát triển:

|   | process 1        || process 2 |                        |
     ------------------  -------------
0                                                            max

cho đến khi chia tách là không thể tránh khỏi:

|   | process 1 part 1 || process 2 |   | process 1 part 2 | |
     ------------------  -----------     ------------------
0                                                            max

Tại điểm này:

• cách duy nhất để dịch các trang là thực hiện tìm kiếm nhị phân trên tất cả các trang của quy trình 1, trong đó có một nhật ký không được chấp nhận (n)
• một sự hoán đổi ra khỏi quy trình 1 phần 1 có thể rất lớn vì phân khúc đó có thể rất lớn

Tuy nhiên, với các trang có kích thước cố định:

• mỗi bản dịch 32 bit chỉ có 2 bộ nhớ đọc: thư mục và bảng trang đi bộ
• mỗi trao đổi là một 4KiB chấp nhận được

Bộ nhớ có kích thước cố định đơn giản là dễ quản lý hơn và đã thống trị thiết kế hệ điều hành hiện tại.

Xem thêm: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work