Mengapa (bukan) segmentasi?

Saya mempelajari sistem operasi dan arsitektur x86, dan ketika saya membaca tentang segmentasi dan paging, saya tentu penasaran bagaimana OS modern menangani manajemen memori. Dari apa yang saya temukan Linux dan sebagian besar sistem operasi lainnya pada dasarnya menghindari segmentasi demi paging. Beberapa alasan untuk ini yang saya temukan adalah kesederhanaan dan portabilitas.

Apa kegunaan praktis yang ada untuk segmentasi (x86 atau yang lain) dan apakah kita akan pernah melihat sistem operasi yang kuat menggunakannya atau apakah mereka akan terus mendukung sistem berbasis paging.

Sekarang saya tahu ini adalah pertanyaan yang dimuat tetapi saya ingin tahu bagaimana segmentasi akan ditangani dengan sistem operasi yang baru dikembangkan. Apakah masuk akal untuk memilih paging sehingga tidak ada yang akan mempertimbangkan pendekatan yang lebih 'tersegmentasi'? Jika demikian, mengapa?

Dan ketika saya mengatakan segmentasi 'hindari' saya menyiratkan bahwa Linux hanya menggunakannya sejauh yang diperlukan. Hanya 4 segmen untuk pengguna dan kode kernel / segmen data. Saat membaca dokumentasi Intel, saya merasa bahwa segmentasi dirancang dengan solusi yang lebih kuat. Kemudian lagi saya diberitahu pada banyak kesempatan betapa rumitnya x86.

Saya menemukan anekdot yang menarik ini setelah dikaitkan dengan 'pengumuman' asli Linux Torvald untuk Linux. Dia mengatakan ini beberapa posting kemudian:

Cukup, saya akan mengatakan bahwa porting tidak mungkin. Ini sebagian besar dalam C, tetapi kebanyakan orang tidak akan menyebut apa yang saya tulis C. Ini menggunakan semua fitur yang mungkin dari 386 yang bisa saya temukan, karena itu juga sebuah proyek untuk mengajari saya tentang 386. Seperti yang telah disebutkan, ia menggunakan MMU , untuk paging (belum ke disk) dan segmentasi. Ini adalah segmentasi yang menjadikannya BENAR-BENAR 386 bergantung (setiap tugas memiliki segmen 64 MB untuk kode & data - maks 64 tugas dalam 4Gb. Siapa pun yang membutuhkan lebih dari 64 Mb / tugas - cookie yang sulit).

Saya kira eksperimen saya sendiri dengan x86 membuat saya mengajukan pertanyaan ini. Linus tidak memiliki StackOverflow, jadi dia hanya mengimplementasikannya untuk mencobanya.

Dengan segmentasi akan, misalnya, mungkin untuk menempatkan setiap objek yang dialokasikan secara dinamis (malloc) di segmen memori sendiri. Perangkat keras akan memeriksa batas segmen secara otomatis, dan seluruh kelas bug keamanan (buffer overruns) akan dihilangkan.

Juga, karena semua offset segmen dimulai dari nol, semua kode yang dikompilasi secara otomatis akan menjadi independen. Memanggil ke DLL lain akan mendidih ke panggilan jauh dengan offset konstan (tergantung pada fungsi yang dipanggil). Ini akan sangat menyederhanakan tautan dan pemuat.

Dengan 4 cincin perlindungan, dimungkinkan untuk membuat kontrol akses yang lebih halus (dengan paging Anda hanya memiliki 2 tingkat perlindungan: pengguna dan pengawas) dan kernel OS yang lebih kuat. Misalnya, hanya dering 0 yang memiliki akses penuh ke perangkat keras. Dengan memisahkan kernel inti OS dan driver perangkat menjadi cincin 0 dan 1, Anda dapat membuat OS microkernel yang lebih kuat dan sangat cepat di mana sebagian besar pemeriksaan akses yang relevan akan dilakukan oleh HW. (Driver perangkat bisa mendapatkan akses ke perangkat keras melalui bitmap akses I / O di TSS.)

Namun .. x86 agak terbatas. Ia hanya memiliki 4 register segmen data "gratis"; memuat ulang mereka agak mahal, dan dimungkinkan untuk secara bersamaan mengakses hanya 8192 segmen. (Dengan asumsi Anda ingin memaksimalkan jumlah objek yang dapat diakses, sehingga GDT hanya memegang deskriptor sistem dan deskriptor LDT.)

Sekarang, dengan segmentasi mode 64-bit digambarkan sebagai "warisan" dan pemeriksaan batas perangkat keras hanya dilakukan dalam keadaan terbatas. IMHO, kesalahan besar. Sebenarnya saya tidak menyalahkan Intel, saya kebanyakan menyalahkan pengembang, yang sebagian besar berpikir bahwa segmentasi "terlalu rumit" dan merindukan ruang alamat datar. Saya juga menyalahkan penulis OS yang kurang memiliki imajinasi untuk menempatkan segmentasi dengan baik. (AFAIK, OS / 2 adalah satu-satunya sistem operasi yang memanfaatkan sepenuhnya fitur segmentasi.)

Jawaban singkatnya adalah segmentasi adalah peretasan, yang digunakan untuk membuat prosesor dengan kemampuan terbatas untuk mengatasi memori yang melebihi batas itu.

Dalam kasus 8086, ada 20 garis alamat pada chip, yang berarti bahwa secara fisik dapat mengakses 1Mb memori. Namun, arsitektur internal didasarkan pada pengalamatan 16 bit, mungkin karena keinginan untuk mempertahankan konsistensi dengan 8080. Jadi set instruksi termasuk register segmen yang akan dikombinasikan dengan indeks 16-bit untuk memungkinkan pengalamatan memori penuh 1Mb . 80286 memperluas model ini dengan MMU sejati, untuk mendukung perlindungan berbasis segmen dan menangani lebih banyak memori (iirc, 16Mb).

Dalam kasus PDP-11, model prosesor selanjutnya memberikan segmentasi ke ruang Instruksi dan Data, sekali lagi untuk mendukung keterbatasan ruang alamat 16-bit.

Masalah dengan segmentasi sederhana: program Anda harus secara eksplisit mengatasi keterbatasan arsitektur. Dalam kasus 8086, ini berarti bahwa blok memori bersebelahan terbesar yang dapat Anda akses adalah 64k. jika Anda perlu mengakses lebih dari itu, Anda harus mengubah register segmen Anda. Yang berarti, untuk seorang programmer C, bahwa Anda harus memberi tahu kompiler C seperti apa pointer yang harus dihasilkan.

Jauh lebih mudah untuk memprogram MC68k, yang memiliki arsitektur internal 32-bit dan ruang alamat fisik 24-bit.

Untuk 80x86 ada 4 opsi - "tidak ada", hanya segmentasi, paging saja, dan keduanya segmentasi dan paging.

Untuk "tidak ada" (tanpa segmentasi atau paging) Anda berakhir dengan tidak ada cara mudah untuk melindungi proses dari dirinya sendiri, tidak ada cara mudah untuk melindungi proses dari satu sama lain, tidak ada cara untuk menangani hal-hal seperti fragmentasi ruang alamat fisik, tidak ada cara untuk menghindari posisi kode independen, dll. Terlepas dari semua masalah ini, mungkin (secara teori) berguna dalam beberapa situasi (misalnya perangkat tertanam yang hanya menjalankan satu aplikasi; atau mungkin sesuatu yang menggunakan JIT dan memvirtualisasikan semuanya).

Hanya untuk segmentasi; hampir memecahkan masalah "melindungi proses dari dirinya sendiri", tetapi butuh banyak usaha untuk membuatnya dapat digunakan ketika suatu proses ingin menggunakan lebih dari 8192 segmen (dengan asumsi satu LDT per proses), yang membuatnya sebagian besar rusak. Anda hampir menyelesaikan masalah "melindungi proses dari satu sama lain"; tetapi perangkat lunak berbeda yang berjalan pada tingkat hak yang sama dapat memuat / menggunakan segmen masing-masing (ada cara untuk mengatasinya - memodifikasi entri GDT selama transfer kontrol dan / atau menggunakan LDT). Itu juga sebagian besar memecahkan masalah "posisi kode independen" (itu dapat menyebabkan masalah "kode tergantung segmen" tapi itu jauh kurang signifikan). Itu tidak melakukan apa pun untuk masalah "fragmentasi ruang alamat fisik".

Untuk paging saja; itu tidak memecahkan banyak masalah "melindungi proses dari dirinya sendiri" (tapi mari kita jujur ​​di sini, ini hanya benar-benar masalah untuk debugging / menguji kode yang ditulis dalam bahasa yang tidak aman, dan ada alat yang jauh lebih kuat seperti Valgrind pula). Ini sepenuhnya memecahkan masalah "melindungi proses dari satu sama lain", sepenuhnya memecahkan masalah "posisi kode independen", dan sepenuhnya memecahkan masalah "fragmentasi ruang alamat fisik". Sebagai bonus tambahan itu membuka beberapa teknik yang sangat kuat yang tidak sedekat praktis tanpa paging; termasuk hal-hal seperti "copy on write", file yang dipetakan memori, penanganan ruang swap yang efisien, dll.

Sekarang Anda akan berpikir bahwa menggunakan segmentasi dan paging akan memberi Anda manfaat dari keduanya; dan secara teori itu bisa, kecuali bahwa satu-satunya manfaat yang Anda peroleh dari segmentasi (yang tidak dilakukan lebih baik dengan paging) adalah solusi untuk masalah "melindungi proses dari dirinya sendiri" yang tidak ada yang benar-benar peduli. Dalam praktiknya apa yang Anda dapatkan adalah kompleksitas keduanya dan overhead keduanya, untuk keuntungan yang sangat kecil.

Inilah sebabnya mengapa hampir semua OS yang dirancang untuk 80x86 tidak menggunakan segmentasi untuk manajemen memori (mereka menggunakannya untuk hal-hal seperti per-CPU dan penyimpanan per-tugas, tetapi itu sebagian besar hanya untuk kenyamanan untuk menghindari mengkonsumsi register tujuan umum yang lebih berguna untuk ini sesuatu).

Tentu saja produsen CPU tidak konyol - mereka tidak akan menghabiskan waktu dan uang untuk mengoptimalkan sesuatu yang mereka tahu tidak ada yang digunakan (mereka akan mengoptimalkan sesuatu yang hampir semua orang gunakan). Karena alasan ini produsen CPU tidak mengoptimalkan segmentasi, yang membuat segmentasi lebih lambat daripada yang seharusnya, yang membuat pengembang OS ingin menghindarinya lebih banyak lagi. Sebagian besar mereka hanya mempertahankan segmentasi untuk kompatibilitas ke belakang (yang penting).

Akhirnya, AMD merancang mode panjang. Tidak ada kode 64 bit lama / yang ada untuk dikhawatirkan, jadi (untuk kode 64-bit) AMD menyingkirkan segmentasi sebanyak yang mereka bisa. Ini memberi pengembang OS alasan lain (tidak ada cara mudah untuk port code yang dirancang untuk segmentasi ke 64-bit) untuk terus menghindari segmentasi.

Saya agak terkejut bahwa sepanjang waktu sejak pertanyaan ini diposting bahwa tidak ada yang menyebutkan asal-usul arsitektur memori tersegmentasi dan kekuatan sejati yang mereka mampu.

Sistem asli yang entah diciptakan, atau disempurnakan menjadi bentuk yang berguna, semua fitur yang mengelilingi desain dan penggunaan sistem memori virtual paged tersegmentasi (bersama dengan multi-pemrosesan simetris dan filesystem hirarkis) adalah Multics (dan lihat juga situs Multicians ). Memori tersegmentasi memungkinkan Multics untuk menawarkan tampilan kepada pengguna bahwa semuanya ada dalam memori (virtual), dan memungkinkan tingkat tertinggi berbagi segalanyadalam bentuk langsung (yaitu langsung dialamatkan dalam memori). Sistem file menjadi sekadar peta untuk semua segmen dalam memori. Ketika digunakan secara tepat dengan cara sistematis (seperti dalam Multics) memori tersegmentasi membebaskan pengguna dari banyak beban mengelola penyimpanan sekunder, dan berbagi data, serta komunikasi antar proses. Jawaban lain telah membuat beberapa klaim yang berliku-liku bahwa memori tersegmentasi lebih sulit untuk digunakan, tetapi ini sama sekali tidak benar, dan Multics membuktikannya dengan kesuksesan besar beberapa dekade yang lalu.

Intel membuat versi tersegmentasi dari memori tersegmentasi 80286 yang meskipun cukup kuat, keterbatasannya mencegahnya digunakan untuk apa pun yang benar-benar bermanfaat. 80386 meningkatkan keterbatasan ini, tetapi kekuatan pasar pada saat itu cukup banyak mencegah keberhasilan sistem apa pun yang benar-benar dapat mengambil keuntungan dari perbaikan ini. Pada tahun-tahun sejak itu tampaknya terlalu banyak orang telah belajar untuk mengabaikan pelajaran masa lalu.

Intel juga mencoba sejak awal untuk membangun super-mikro lebih mampu yang disebut iAPX 432 yang akan jauh melampaui apa pun pada saat itu, dan memiliki arsitektur memori tersegmentasi dan fitur lainnya yang sangat berorientasi pada pemrograman berorientasi objek. Implementasi aslinya terlalu lambat, dan tidak ada upaya lebih lanjut untuk memperbaikinya.

Diskusi yang lebih terperinci tentang bagaimana Multics menggunakan segmentasi dan paging dapat ditemukan dalam makalah Paul Green, Multics Virtual Memory - Tutorial dan Refleksi

Segmentasi adalah peretasan / penyelesaian untuk memungkinkan memori hingga 1MB ditangani oleh prosesor 16 bit - biasanya hanya 64 ribu memori yang dapat diakses.

Ketika prosesor 32 bit muncul, Anda dapat menangani hingga 4GB memori dengan model memori datar dan tidak ada lagi kebutuhan untuk segmentasi - Register segmen ditujuan kembali sebagai penyeleksi untuk GDT / paging dalam mode terproteksi (walaupun Anda dapat memiliki mode terproteksi 16-bit).

Juga mode memori datar jauh lebih nyaman untuk kompiler - Anda dapat menulis program tersegmentasi 16-bit dalam C , tetapi agak rumit. Model memori datar membuat semuanya lebih sederhana.

Beberapa arsitektur (seperti ARM) sama sekali tidak mendukung segmen memori. Jika Linux bergantung pada sumber pada segmen, ia tidak dapat dengan mudah dipindahkan ke arsitektur tersebut.

Melihat gambaran yang lebih luas, kegagalan segmen memori berkaitan dengan popularitas C dan pointer yang terus menerus. Pengembangan C lebih praktis pada arsitektur dengan memori datar; dan jika Anda ingin memori datar, Anda memilih paging memori.

Ada masa sekitar pergantian tahun 80-an ketika Intel, sebagai sebuah organisasi, mengantisipasi popularitas Ada di masa depan dan bahasa pemrograman tingkat tinggi lainnya. Ini pada dasarnya dari mana beberapa kegagalan mereka yang lebih spektakuler, seperti segmentasi memori APX432 dan 286 yang mengerikan, berasal. Dengan 386 mereka menyerah pada pemrogram memori datar; paging dan TLB ditambahkan dan segmen dibuat ulang ke 4GB. Dan kemudian AMD pada dasarnya menghapus segmen dengan x86_64 dengan membuat basis reg menjadi tidak peduli / tersirat-0 (kecuali untuk fs? Untuk TLS saya pikir?)

Karena itu, keuntungan dari segmen memori jelas - berpindah ruang alamat tanpa harus mengisi ulang TLB. Mungkin suatu hari nanti seseorang akan membuat CPU kompetitif-kinerja yang mendukung segmentasi, kita dapat memprogram OS berorientasi segmentasi untuk itu, dan programmer dapat membuat Ada / Pascal / D / Rust / lain-langage-yang-tidak-memerlukan-datar Program -memory untuk itu.

Segmentasi adalah beban besar bagi pengembang aplikasi. Di sinilah dorongan besar datang untuk menghilangkan segmentasi.

Menariknya saya sering bertanya-tanya seberapa jauh i86 bisa lebih baik jika Intel menghapus semua dukungan warisan untuk mode lama ini. Di sini lebih baik menyiratkan daya yang lebih rendah dan mungkin operasi lebih cepat.

Saya kira orang bisa berpendapat bahwa Intel membasahi susu dengan segmen 16bit yang mengarah ke semacam pemberontakan pengembang. Tapi mari kita hadapi itu ruang alamat 64k bukanlah apa-apa terutama ketika Anda melihat aplikasi modern. Pada akhirnya mereka harus melakukan sesuatu karena persaingan dapat dan melakukan pasar secara efektif terhadap masalah ruang alamat i86.

Segmentasi menyebabkan terjemahan halaman lebih lambat dan bertukar

Karena alasan itu, segmentasi sebagian besar dibatalkan pada x86-64.

Perbedaan utama di antara mereka adalah:

• paging membagi memori menjadi potongan-potongan berukuran tetap
• segmentasi memungkinkan lebar yang berbeda untuk setiap chunk

Meskipun mungkin tampak lebih pintar untuk memiliki lebar segmen yang dapat dikonfigurasi, saat Anda menambah ukuran memori untuk suatu proses, fragmentasi tidak dapat dihindari, misalnya:

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

pada akhirnya akan menjadi seperti proses 1 tumbuh:

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

sampai perpecahan tidak bisa dihindari:

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

Pada saat ini:

• satu-satunya cara untuk menerjemahkan halaman adalah dengan melakukan pencarian biner pada semua halaman proses 1, yang mengambil log yang tidak dapat diterima (n)
• swap keluar dari proses 1 bagian 1 bisa jadi besar karena segmen itu bisa sangat besar

Namun dengan halaman berukuran tetap:

• setiap terjemahan 32-bit hanya membaca 2 memori: direktori dan tabel berjalan halaman
• setiap swap adalah 4KiB yang dapat diterima

Potongan memori berukuran tetap hanya lebih mudah dikelola, dan telah mendominasi desain OS saat ini.

Lihat juga: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work