Neden (değil) segmentasyon?

İşletim sistemleri ve x86 mimarisi üzerine çalışıyorum ve bölümlendirme ve sayfalama hakkında okurken, modern işletim sistemlerinde bellek yönetimini nasıl idare ettiğini merak ediyordum. Linux'u ve diğer işletim sistemlerini bulduklarımdan dolayı, temelde disk belleği disk belleği lehine çevrildi. Bunun bulduğum sebeplerin bir kısmı basitlik ve taşınabilirlikti.

Hangi pratik kullanımları segmentasyon için vardır (x86 veya başka türlü) ve onu kullanan güçlü işletim sistemlerini görecek miyiz, yoksa çağrı tabanlı bir sistemi desteklemeye devam edecekler mi.

Şimdi bunun yüklü bir soru olduğunu biliyorum, ancak yeni geliştirilen işletim sistemlerinde bölümlemenin nasıl ele alınacağını merak ediyorum. Kimsenin daha “bölünmüş” bir yaklaşım olarak değerlendirmeyeceği bir çağrı yapmayı tercih etmek mantıklı geliyor mu? Öyleyse neden?

Ve 'shun' segmentasyonu dediğimde, Linux'un sadece sahip olduğu kadar kullandığını ima ediyorum. Kullanıcı ve çekirdek kodu / veri bölümleri için sadece 4 bölüm. Intel belgelerini okurken, bölümlendirmenin daha sağlam çözümler düşünülerek tasarlandığı hissine kapıldım. Sonra yine birçok kez x86'nın ne kadar karmaşık olabileceği söylendi.

Bu ilginç anekdotu Linux Torvald'ın Linux için orjinal ilanına bağladıktan sonra buldum. Bunu birkaç mesaj sonra söyledi:

Basitçe söylemek gerekirse, taşıma imkansızdır. Çoğunlukla C cinsindendir, ancak çoğu kişi benim yazdıklarımın C adını vermez. 386'nın akla gelebilecek her özelliğini kullanırım, aynı zamanda 386 hakkında bana öğretmek için bir proje olduğu için bulabilirim. , hem disk belleği (hem de diske değil) hem de segmentasyon için. GERÇEKTEN 386'ya bağımlı kılan bölümlemedir (her görevin kod ve veri için 64Mb'lik bir bölümü vardır - 4Gb'de maksimum 64 görev. 64 MB / görevden daha fazla çerez isteyen herkes).

Sanırım x86 ile olan kendi deneyimlerim bu soruyu sormamı sağladı. Linus'ta StackOverflow yoktu, bu yüzden denemek için uyguladı.

Segmentasyon ile, örneğin, her dinamik olarak tahsis edilmiş nesneyi (malloc) kendi hafıza segmentine koymak mümkün olacaktır. Donanım, segment limitlerini otomatik olarak kontrol eder ve bütün güvenlik hataları sınıfı (arabellek taşması) ortadan kaldırılır.

Ayrıca, tüm segment ofsetleri sıfırdan başladığından, derlenmiş tüm kodlar otomatik olarak konum bağımsız olacaktır. Başka bir DLL dosyasını çağırmak, sabit dengelemeli uzak bir aramaya (çağrılan işleve bağlı olarak) indirgenir. Bu, bağlayıcıları ve yükleyicileri büyük ölçüde basitleştirir.

4 koruma halkası ile, daha iyi ayarlanmış erişim kontrolü (disk belleği ile sadece 2 koruma seviyesine sahip olursunuz: kullanıcı ve gözetmen) ve daha sağlam işletim sistemi çekirdeği oluşturmak mümkündür. Örneğin, yalnızca 0 halkası donanıma tam erişime sahiptir. Çekirdek işletim sistemi çekirdeği ve aygıt sürücülerini 0 ve 1 numaralı halkalara ayırarak, ilgili erişim denetimlerinin çoğunun HW tarafından yapılacağı daha sağlam ve çok hızlı bir mikro çekirdek işletim sistemi yapabilirsiniz. (Aygıt sürücüleri, TSS'deki G / Ç erişim bitmap'i aracılığıyla donanıma erişebilir.)

Ancak .. x86 biraz sınırlıdır. Sadece 4 adet "serbest" veri bölümü kaydı var; Bunları yeniden yüklemek oldukça pahalıdır ve aynı anda yalnızca 8192 segmente erişmek mümkündür. (Erişilebilir nesne sayısını en üst düzeye çıkarmak istediğinizi varsayalım, bu nedenle GDT yalnızca sistem tanımlayıcılarını ve LDT tanımlayıcılarını tutar.)

Şimdi, 64-bit mod ile segmentasyon "eski" olarak tanımlanır ve donanım limit kontrolleri yalnızca sınırlı koşullarda yapılır. IMHO, BÜYÜK bir hata. Aslında Intel'i suçlamıyorum, çoğunlukla bölümlendirmenin "çok karmaşık" olduğunu ve düz adres alanı için can attığını düşünen geliştiricileri suçluyorum. Ayrıca, bölümlendirmeyi iyi kullanmak için hayal gücünden yoksun olan işletim sistemi yazarlarını da suçluyorum. (AFAIK, OS / 2, segmentasyon özelliklerini tam olarak kullanan tek işletim sistemi idi.)

Kısa cevap, bölümlendirmenin hafızayı ele alma konusunda sınırlı bir yeteneği olan bir işlemciyi bu sınırları aşması için kullanılan bir kesmek olmasıdır.

8086 durumunda, çipte 20 adres satırı vardı, bu fiziksel olarak 1Mb belleğe erişebileceği anlamına geliyordu. Bununla birlikte, iç mimari, muhtemelen 8080 ile tutarlılığı sürdürme arzusundan ötürü 16 bit adreslemeye dayanıyordu. Bu nedenle, komut seti, 1 MB'lık tam belleğin adreslenmesini sağlamak için 16 bitlik dizinlerle birleştirilebilecek bölüm kayıtlarını içeriyordu. . 80286, daha fazla belleğin (iirc, 16Mb) segment korumasını ve adreslenmesini desteklemek için bu modeli gerçek bir MMU ile genişletti.

PDP-11 durumunda, işlemcinin sonraki modelleri, 16-bitlik bir adres alanının sınırlamalarını desteklemek için yine Talimat ve Veri alanlarına bir bölümleme sağlamıştır.

Bölümlendirmeyle ilgili sorun basittir: Programınız açıkça mimarinin sınırlamaları etrafında çalışmalıdır. 8086 örneğinde, bu, erişebileceğiniz en büyük bitişik hafıza bloğunun 64k olduğu anlamına geliyordu. Bundan daha fazlasına erişmeniz gerekirse, segment kayıtlarınızı değiştirmeniz gerekir. Bu, bir C programcısı için, C derleyicisine ne tür göstericiler üretmesi gerektiğini söylemeniz gerektiği anlamına geliyordu.

32 bit iç mimariye ve 24 bit fiziksel adres alanına sahip olan MC68k'i programlamak çok daha kolaydı.

80x86 için 4 seçenek vardır - "hiçbir şey", yalnızca bölümleme, yalnızca sayfalama ve hem bölümleme hem de sayfalama.

"Hiçbir şey" için (segmentasyon veya çağrı yok), bir işlemi kendinden korumanın kolay bir yolunu, işlemleri birbirinden korumanın kolay bir yolunu, fiziksel adres alanı parçalanması gibi şeyleri idare etmenin, pozisyondan kaçınmanın bir yolunu bulmazsınız bağımsız kod, vb. Bütün bu sorunlara rağmen (teoride) bazı durumlarda yararlı olabilir (örneğin, yalnızca bir uygulamayı çalıştıran gömülü aygıt veya belki de JIT kullanan ve her şeyi sanallaştıran bir şey).

Sadece bölümleme için; Neredeyse "bir süreci kendinden korumak" sorununu çözüyor, ancak bir işlem 8192'den fazla segmenti (işlem başına bir LDT varsayarsak) kullanmak istediğinde kullanılabilir hale getirmek için çok fazla çaba harcıyor. Neredeyse "süreçleri birbirimizden koru" problemini çözüyorsunuz; ancak aynı ayrıcalık seviyesinde çalışan farklı yazılım parçaları birbirlerinin bölümlerini yükleyebilir / kullanabilir (bunun üzerinde çalışmanın yolları vardır - kontrol transferleri sırasında ve / veya LDT'leri kullanarak). Aynı zamanda çoğunlukla “pozisyon bağımsız kod” problemini çözer (“segmente bağımlı kod” problemine neden olabilir ama bu çok daha az önemli). “Fiziksel adres alanı parçalanması” sorunu için hiçbir şey yapmaz.

Sadece çağrı için; “bir süreci kendinden koru” problemini fazla çözmez (ama burada dürüst olalım, bu gerçekten güvenli olmayan dillerde yazılmış kod hata ayıklama / test etme için bir problemdir ve yine de valgrind gibi çok daha güçlü araçlar var). Tamamen “süreçleri birbirimizden koru” problemini çözer, “pozisyon bağımsız kodu” problemini tamamen çözer ve “fiziksel adres alanı parçalanma” problemini tamamen çözer. Ek bir bonus olarak, çağrı yapmadan pratik bir yere yakın olmayan bazı çok güçlü teknikleri açar; "yazma üzerine kopyala", hafızaya eşlenmiş dosyalar, verimli takas alanı işleme vb.

Şimdi hem bölümlemeyi hem de sayfalamayı kullanmanın ikisinin de faydalarını sağlayacağını düşünebilirsiniz; Teorik olarak, bölümlemeden elde ettiğiniz tek fayda (sayfalama ile daha iyi yapılmayan), hiç kimsenin gerçekten umursamadığı “bir süreci kendinden koruma” sorununa bir çözüm olabilir. Uygulamada elde ettiğiniz şey, çok az yarar için her ikisinin de karmaşıklığı ve her ikisinin de ek yüküdür.

Bu nedenle 80x86 için tasarlanan hemen hemen tüm işletim sistemlerinin bellek yönetimi için segmentasyon kullanmaması (CPU başına ve görev başına depolama gibi şeyler için kullanıyorlar, ancak bu genellikle bunlar için daha yararlı bir genel amaçlı kayıt tüketmekten kaçınmak için kolaylık sağlıyor. bir şeyler).

Tabii ki CPU üreticileri aptal değil - kimsenin kullanmadığı bir şeyi optimize etmek için zaman ve para harcayacaklar (neredeyse herkesin kullandığı bir şeyi optimize edecekler). Bu nedenle CPU üreticileri segmentasyonu optimize etmiyor, bu da segmentasyonu olabileceğinden daha yavaş hale getiriyor ve bu da OS geliştiricilerin bundan daha fazla kaçınmasını istiyor. Çoğunlukla sadece geriye dönük uyumluluk için segmentasyonu tuttu (bu önemli).

Sonunda, AMD uzun mod tasarladı. Endişelenecek eski / mevcut 64 bit kod yoktu, bu yüzden (64 bit kod için) AMD olabildiğince çok bölümlemeden kurtuldu. Bu, işletim sistemi geliştiricilerine, segmentasyondan kaçınmaya devam etmeleri için başka bir neden (bölümleme için tasarlanmış 64-bit'e bağlantı noktası kodunun kolay bir yolu yoktur) verdi.

Bu soru gönderildiğinden beri sürekli olarak bölümlenmiş bellek mimarilerinin kökenlerinden ve karşılayabilecekleri gerçek güçten hiç kimsenin bahsetmediğinden şaşırdım.

Ya icat ya da yararlı bir şekilde rafine özgün sistem, bütün (simetrik çoklu işleme ve hiyerarşik dosya sistemleri ile birlikte) parçalara ayrılmış bir disk belleği sanal bellek sistemlerinin tasarım ve kullanımıyla ilgili özellikleri olan Multics (ve ayrıca bkz Multicians sitesi). Bölünmüş bellek Multics'in kullanıcıya her şeyin (sanal) bellekte olduğu görüşünü sunmasını sağlar ve her şeyin en üst düzeyde paylaşılmasını sağlardoğrudan biçimde (yani doğrudan bellekte adreslenebilir). Dosya sistemi basitçe bellekteki tüm bölümler için bir harita haline gelir. Düzgün bir şekilde sistematik bir şekilde kullanıldığında (Multics'te olduğu gibi) bölümlendirilmiş bellek, kullanıcıyı ikincil depolamayı yönetme, veri paylaşımı ve süreçler arası iletişimi yönetme sıkıntılarından kurtarır. Diğer cevaplar, bölünmüş hafızanın kullanımının daha zor olduğunu bazı el dalgalı iddialarda bulundular, ancak bu sadece doğru değil ve Multics, on yıllar önce yankılanan bir başarı ile olduğunu kanıtladı.

Intel, 80286'nın parçalanmış hafızasının parçalanmış bir versiyonunu yarattı, ancak oldukça güçlü olmasına rağmen, kısıtlamaları gerçekten yararlı olan her şey için kullanılmasını engelledi. 80386 bu sınırlamalar üzerinde gelişti, ancak o sırada piyasa güçleri bu gelişmelerden gerçekten faydalanabilecek herhangi bir sistemin başarısını büyük ölçüde engelledi. Görünüşe göre, çok fazla insan geçmişin derslerini görmezden gelmeyi öğrendi.

Intel, iAPX 432 adı verilen ve o sırada başka bir şeyi çok daha aşacak olan daha yetenekli bir süper mikro oluşturmak için de çaba sarf etti ve bölümlenmiş bellek mimarisine ve nesne yönelimli programlamaya yönelik güçlü özelliklere sahip diğer özelliklere sahipti. Orijinal uygulama yine de çok yavaştı ve düzeltmek için başka girişimde bulunulmadı.

Multics'in bölümlendirme ve sayfalamanın nasıl kullanıldığına dair daha ayrıntılı bir tartışma Paul Green'in Multics Sanal Belleği - Öğretici ve Yansımalar adlı makalesinde bulunabilir.

Bölümleme, 16 MB'lik bir işlemci tarafından 1 MB'a kadar belleğin ele alınmasına izin vermek için bir kesmek / geçici çözümdü - normalde sadece 64K belleğe erişilebiliyordu.

32 bit işlemciler geldiğinde, düz bellek modeliyle 4 GB belleğe kadar hitap edebiliyordunuz ve artık segmentasyona gerek kalmıyordu - Segment kayıtları GDT / disk belleği için seçici modda korumalı moddaydı. korumalı modu var 16-bit).

Ayrıca düz bellek modu derleyiciler için çok daha uygundur - C de 16 bitlik bölümlenmiş programlar yazabilirsiniz , ancak biraz hantaldır. Düz bellek modeli her şeyi kolaylaştırır.

Bazı mimariler (ARM gibi) hiç bir bellek parçasını desteklemez. Eğer Linux segmentlere kaynağa bağlı olsaydı, bu mimarilere çok kolay bir şekilde aktarılamazdı.

Daha geniş resme bakıldığında, bellek bölümlerinin arızası C ve işaretçi aritmetiğinin devam eden popülerliği ile ilgiliydi. C geliştirme, düz belleğe sahip bir mimaride daha pratiktir; ve düz bellek istiyorsanız, bellek aramayı seçersiniz.

80'lerin başında, bir organizasyon olarak Intel, Ada'nın ve diğer üst seviye programlama dillerinin gelecekteki popülerliğini öngördüğü zamanlar vardı. Bu temelde, korkunç APX432 ve 286 bellek bölümlemesi gibi bazı daha muhteşem başarısızlıklarının ortaya çıktığı yerdir. 386 ile düz bellek programlayıcılarına teslim oldular; sayfalama ve bir TLB eklendi ve bölümler 4GB'a yeniden boyutlandırılabilir hale getirildi. Ve sonra AMD temel olarak x86_64 ile segmentleri kaldırdı, üsteliği umursamadım / ima ettiğim-0 (TLS için fs? Hariç?)

Bununla birlikte, bellek bölümlerinin avantajları açıktır - bir TLB'yi yeniden doldurmak zorunda kalmadan adres alanlarını değiştirmek. Belki bir gün biri bölümlendirmeyi destekleyen performans açısından rekabetçi bir CPU oluşturabilir, bunun için bölümlendirmeye yönelik bir işletim sistemi programlayabiliriz ve programcılar Ada / Pascal / D / Rust / başka bir langage-gerektirmeyen-düz yapabilir -Bunun için hafıza programları.

Segmentasyon, uygulama geliştiricileri için büyük bir yüktür. İşte işte bu büyük itiş bölümleme yapmaktan çıktı.

İlginçtir ki, Intel bu eski modlar için tüm eski desteği çıkarsa, i86'nın ne kadar iyi olabileceğini merak ediyorum. Burada daha iyi, daha düşük güç ve daha hızlı çalışma anlamına gelir.

Sanırım Intel sütü 16bit segmentli bir çeşit geliştiricinin isyanına yol açacağı konusunda tartışabilir. Ama şunu söyleyelim ki 64k adres alanı özellikle modern uygulamaya baktığınızda hiçbir şey değil. Sonunda bir şey yapmak zorunda kaldılar çünkü rekabet, i86'nın adres alanı sorunlarına karşı etkili bir şekilde pazar yapabiliyor ve pazar yapıyordu.

Segmentasyon, sayfa çevirilerinin yavaşlamasına ve değiştirilmesine yol açar

Bu nedenlerden dolayı, segmentasyon büyük ölçüde x86-64'te düşmüştür.

Aralarındaki temel fark şudur:

• disk belleği hafızayı sabit boyutlu parçalara böler
• segmentasyon, her yığın için farklı genişliklere izin verir

Yapılandırılabilir segment genişliklerine sahip olmak daha akıllıca görünse de, bir işlem için bellek boyutunu artırırken parçalanma kaçınılmazdır, örneğin:

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

sonunda süreç 1 büyüdükçe olacak:

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

bölünme kaçınılmaz olana kadar:

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

Bu noktada:

• sayfaları çevirmenin tek yolu, kabul edilemez bir günlük (n) alan 1. işlemin tüm sayfalarında ikili arama yapmaktır.
• 1. bölümdeki 1. işlemden bir değişim çok büyük olabilir; çünkü o bölüm çok büyük olabilir.

Bununla birlikte, sabit boyutlu sayfalarda:

• Her 32-bit çeviri sadece 2 hafıza okur: dizin ve sayfa tablosu yürüyüşü
• Her takas kabul edilebilir bir 4KiB'dir.

Sabit boyutlu bellek parçaları daha kolay yönetilebilir ve mevcut işletim sistemi tasarımına hâkim.

Ayrıca bakınız: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work