İlk Linux geliştiricileri neden önleyici olmayan bir çekirdek uygulamayı seçtiler? Senkronizasyonu kaydetmek mi?
Bildiğim kadarıyla, Linux 90'ların başında, PC'lerin tek bir işlemciye sahip olduğu zaman geliştirildi. Önleyici olmayan bir çekirdek bu tür bilgisayarlarda ne avantaj sağlar? Ancak neden çok çekirdekli işlemciler tarafından avantaj azalıyor?
Yanıtlar:
Linux çekirdeği bağlamında, insanlar pre-emption hakkında konuştuğunda, genellikle çekirdeğin kendini kesme yeteneğine atıfta bulunurlar - esasen çekirdek kodunu çalıştırırken görevleri değiştirir. Bunun olmasına izin vermek oldukça karmaşıktır, bu muhtemelen çekirdeğin önceden boş olması için uzun zaman almasının ana sebebidir.
Başlangıçta çoğu çekirdek kodu, büyük çekirdek kilidi tarafından korunduğu için kesilemedi. Bu kilit gittikçe daha fazla çekirdek kodundan aşamalı olarak ortadan kaldırıldı ve paralel olarak (SMP sistemleri daha yaygın hale geldikçe daha fazla önem kazandıran) paralel olarak çekirdeğe birden fazla eşzamanlı çağrı yapılmasına izin verildi. Ama bu hala çekirdeğin kendisini önceden boş bırakmadı; bu da daha fazla gelişme PREEMPT_RTgerektirdi, sonunda ana hat çekirdeğinde birleştirilen (ve yine de BKL'yi önceden kullanabilen) yama kümesinde doruğa ulaştı . Günümüzde çekirdek, peşinde olduğunuz verim ve gecikme özelliklerine bağlı olarak az ya da çok önceden çıkarılabilir olacak şekilde yapılandırılabilir; ayrıntılar için ilgili çekirdek yapılandırmasına bakın.
Çekirdek yapılandırmasındaki açıklamalardan da görebileceğiniz gibi, pre-emption eşzamanlılığı değil verimi ve gecikmeyi etkiler. Tek CPU sistemlerinde, önleme hala yararlıdır çünkü olayların daha kısa reaksiyon süreleri ile işlenmesine izin verir; ancak, aynı zamanda daha düşük verimle sonuçlanır (çünkü çekirdek zaman değiştirme görevlerini harcar). Ön emiş, tek veya birden fazla CPU sistemindeki herhangi bir CPU'nun başka bir göreve daha hızlı geçmesine izin verir. Çoklu CPU sistemlerinde sınırlayıcı faktör öntanımlı değildir, kilitler, büyük veya başka türlü: herhangi bir zaman kodu kilitlendiğinde, başka bir CPU'nun aynı eylemi gerçekleştirmeye başlayamayacağı anlamına gelir.
Önleyici çekirdek yalnızca Büyük Çekirdek Kilidi olmadığı anlamına gelir .
Linux, ilk anından beri önleyici çoklu görevlere sahipti (yani kullanıcı kodu öngörüldü) (bildiğim kadarıyla Linus tarafından funet ftp sunucusuna yüklenen ilk Linux 0.0.1 zaten önleyici çoklu görevdi). Örneğin, birden fazla sıkıştırma veya derleme işlemi gerçekleştirdiyseniz, bunlar ilk andan itibaren paralel olarak yürütülür.
Aksine - o sırada - yaygın olarak kullanılan Win31. Win31'de, bir görev CPU'yu "çekirdekten" aldıysa, varsayılan olarak işletim sistemine (veya diğer görevlere) ne zaman kontrol verileceğini belirlemek kendi sorumluluğundaydı. Bir işlemin bu özellik için özel bir desteği yoksa (bu da ek programlama çalışması gerektirir), yürütülürken diğer tüm görevler askıya alındı. Win31'e entegre edilen temel uygulamaların çoğu bile çalıştı.
Önleyici çoklu görev, görevlerin CPU'yu istedikleri gibi tahsis etmenin bir yolu olmadığı anlamına gelir. Bunun yerine, zaman dilimlerinin süresi dolarsa, çekirdek CPU'yu onlardan alır. Bu nedenle, önleyici işletim sistemlerinde, kötü yazılmış veya kötü çalışan bir işlem, işletim sistemini donduramaz veya diğer işlemlerin çalışmasını engelleyemez. Linux her zaman kullanıcı alanı süreçleri için önleyici olmuştur.
Büyük Çekirdek Kilidi, bazı durumlarda, çekirdek boşluğunda , yine de bazı kilitlerin olabileceği ve diğer işlemlerin korumalı kodu çalıştırmasını önleyeceği anlamına gelir . Örneğin, olamazdı monte aynı anda birden fazla dosya sistemlerini - montaj şeyler Big Kernel Lock ayırmak için gerekli çünkü birden monte komutları verdiyse, yine, arka arkaya idam edildi.
Çekirdeği önleyici hale getirmek, bu büyük çekirdek kilidini ortadan kaldırmak için gerekliydi, yani aynı anda çalışabilmek için bağ ve diğer görevleri yapmak. Bu büyük bir işti.
Tarihsel olarak, bu SMP'nin (çoklu CPU desteği) artan desteğiyle gerçekten acil hale getirildi. İlk kez, gerçekten çok işlemcili anakartlar vardı. Daha sonra birden fazla CPU ("çekirdek") tek bir yongaya entegre edildi, bugün gerçekten çok CPU'lu ana kartlar zaten nadir (tipik olarak pahalı sunucu sistemlerinde). Ayrıca gerçekten tek çekirdekli sistemler (tek çekirdekli tek bir işlemcinin olduğu yerlerde) nadirdir.
Dolayısıyla, sorunuzun cevabı "önleyici olmamanın nedeni neydi" değil, çünkü her zaman önleyici olmuştur. Asıl soru, önleyici çekirdek uygulamasını gerçekten gerekli kılan şey . Bunun cevabı şudur: çok işlemcili, çok çekirdekli sistemlerin artan oranı.
Bu teknik bir cevap değil , OP tarafından ortaya atılan özel soruya tarihsel bir cevap : "Eski Linux çekirdeklerinin önyargısızlığının nedeni neydi?"
(Ben cevap ve yorumlarında @peterh tarafından açıklandığı gibi, "preemtivite" ile OP bir ya da her ikisi de (bir API) çekirdeğin içinde (bir API) olabilir gerçeği zaman ve / veya Büyük Çekirdek Kilidi.)
Linus Torvalds, işletim sistemlerinin nasıl çalıştığını öğrenmekle ilgilendi ve öğrendiği yol bir tane yazmaktı. Modeli ve tabanı ve ilk geliştirme ortamı, eğitim amaçlı mevcut bir işletim sistemi (yani, bir üretim işletim sistemi değil) olan Minix'ti (bu, açık kaynakta olduğu gibi, o zamanlar - biradaki gibi serbest değildi, ya da).
Bu yüzden, önleme olmaksızın bir çekirdek yazdı (diğer cevaplarda bahsedilen Büyük Çekirdek Kilidi), çünkü yeni işletim sisteminizi eğitim amaçlı olarak hızlı bir şekilde çalıştırmak ve çalıştırmak istiyorsanız bunu yapıyorsunuz: bu şekilde çok daha basit. Kullanıcı programlarının ve cihazlarının eş zamanlı çoklu programlamasını destekleyen bir çekirdek yeterince zordur - çekirdeğin eşzamanlı hale getirilmesi son derece zordur.
O zaman Linux'un nasıl popüler / yararlı / önemli olacağını biliyor olsaydı ... muhtemelen aynı şekilde yapardı. (Sadece IMO, aslında ne düşündüğü hakkında hiçbir fikrim yok.) Çünkü koşmadan önce yürümelisin.
Ve uzun bir süre bu şekilde kaldı, çünkü a) Linux'u bugün (hatta o zamanki gibi) yapmak için yapılması gereken çok fazla iş vardı ve b) değiştirmek büyük bir zor girişim olurdu. (diğer cevaplarda açıklandığı gibi).