Що було причиною непередбачуваності старих ядер Linux?


15

Чому перші розробники Linux вирішили реалізувати неперспективне ядро? Це для збереження синхронізації?

Наскільки мені відомо, Linux був розроблений на початку 90-х, коли ПК мали єдиний процесор. Яку перевагу дає неперспективне ядро ​​на таких ПК? Чому, однак, перевагу зменшують багатоядерні процесори?

Відповіді:


26

У контексті ядра Linux, коли люди говорять про перевагу, вони часто посилаються на здатність ядра перебивати себе - по суті, перемикати завдання під час роботи коду ядра. Дозволити це відбутися досить складно, і це, мабуть, головна причина, що для того, щоб ядро ​​було попередньо завантаженим, потрібно тривалий час.

Спочатку більшість кодів ядра ніяк не можна було перервати, оскільки він був захищений великим замком ядра. Цей замок поступово виключався з все більшої кількості ядерного коду, дозволяючи паралельно здійснювати безліч одночасних дзвінків до ядра (що стало важливішим, оскільки системи SMP стали більш поширеними). Але це все ще не зробило саме ядро ​​попередньо придатним; що все ще зайняло більше розробок, що досягало кульмінації в PREEMPT_RTнаборі патчів, який врешті-решт був об'єднаний в основне ядро ​​(і в будь-якому випадку міг би попередньо використовувати BKL). Сьогодні ядро ​​може бути налаштоване на більш-менш попереднє введення, залежно від характеристик пропускної здатності та затримки, яких ви хочете; Докладніше див. відповідну конфігурацію ядра .

Як видно з пояснень у конфігурації ядра, переважання впливає на пропускну здатність та затримку, а не на одночасність. У системах з одним процесором переважання все ще корисно, оскільки дозволяє обробляти події із меншими часом реакції; однак це також призводить до зниження пропускної здатності (оскільки ядро ​​витрачає завдання на перемикання часу). Попередження дозволяє будь-якому ЦП в одній або декількох системах процесора швидше переходити до іншого завдання. Обмежуючим фактором для систем з декількома процесорами не є попередження, це великі блокування чи інше: будь-який код часу блокується, це означає, що інший процесор не може почати виконувати ту саму дію.


12

Вигідне ядро ​​означає лише, що немає великого блокування ядра .

З самого першого моменту Linux мав попереджувальну багатозадачність (тобто код користувача був сприйнятливим) (наскільки я знаю, найперший Linux 0.0.1, завантажений Лінусом на funet ftp-сервер, був уже попередньою багатозадачністю). Якщо ви виконували, наприклад, кілька процесів стиснення або компіляції, вони виконувалися паралельно з першого моменту.

На противагу - на той час - широко використовується Win31. У Win31, якщо завдання отримало ЦП від "ядра", за замовчуванням його відповідальність визначала, коли повернути управління ОС (або іншим завданням). Якщо процес не мав спеціальної підтримки для цієї функції (що вимагало додаткової роботи з програмування), то під час її виконання всі інші завдання були призупинені. Навіть більшість основних програм, інтегрованих у програму Win31, працювали так.

Переважне багатозадачність означає, що завдання не мають можливості розподілити процесор так, як вони хочуть. Натомість, якщо термін їх часу закінчується, ядро ​​відводить процесор від них. Таким чином, в попереджувальних операційних системах погано записаний або погано функціонуючий процес не може заморозити ОС або уникнути запуску інших процесів. Linux завжди переважав для процесів простору користувача.

Блокування великого ядра означає, що в деяких випадках всередині простору ядра все-таки можуть бути деякі блокування, що не дозволяють іншим процесам запускати захищений код. Наприклад, ви не могли одночасно монтувати декілька файлових систем - якщо ви дали кілька команд монтування, вони все одно виконувались послідовно, оскільки для монтажу речей, необхідних для виділення блокування Big Kernel.

Здійснення переваги ядра вимагало усунення цього великого блокування ядра, тобто створення змонтування та будь-яких інших завдань, які можна було б одночасно виконувати. Це була велика робота.

Історично це було зроблено дуже актуально завдяки зростаючій підтримці SMP (підтримка декількох процесорів). У перший час справді були багатопроцесорні плати. Пізніше декілька процесорів («ядер») були інтегровані в єдиний чіп, сьогодні дійсно багатопроцесорні плати вже рідкісні (вони зазвичай в дорогих серверних системах). Також справді одноядерні системи (де є лише один процесор, з одним ядром) є рідкістю.

Таким чином, відповідь на ваше запитання полягає не в тому, "що було причиною непередбачуваності", оскільки воно завжди було превентивним. Справжнє питання полягає в тому, що зробило попереджувальне виконання ядра справді необхідним . Відповідь на це: зростаюче співвідношення багатопроцесорних багатопроцесорних систем.


Я насправді не розумів :( До версії 2.4 ядра, тільки користувальницькі процеси були попереджуючими, а ядро ​​не було вигідним. Як я відповідав комусь раніше, я вважаю, що причиною було збереження роботи над тупиками синхронізації, що могло статися з попередженням впровадження одноядерного процесу. Як ви думаєте?
Нарден

@Narden Я не знаю, ти це читав. Приблизно до 1.3 або 2.0, лише один процес може знаходитися в просторі ядра, навіть якщо запускаються кілька процесів. Це обмеження було усунено приблизно з 2.0. Приблизно до 2.4 існував великий замок ядра (тобто одночасне встановлення декількох файлових систем не працювало).
петерх

@Narden Але це не спільна багатозадачність, жодного процесу для навмисного повернення процесора до планувальника завдань не було. Так, причиною BKL було, ймовірно, що це зробити правильно, є велика робота: 1) блокування потрібно розділити 2) використовувати незахищені структури даних, якщо це можливо 3) розбиті блокування призводять до тупиків / lavelocks, це, як правило, особливо брудні, важко виправлені помилки, їх слід знайти та виправити 4) усі драйвери повинні бути перенесені на зміни в API ядра ядра.
петерх

Я читав його, коли шукав відповідь, і він також подається як інформація в курсі, який я беру під назвою Операційні системи.
Нарден

1
Блокування великого ядра не дозволяло іншим потокам потрапляти в ядро ​​під час виконання одного в ядрі. Було дозволено лише один потік, тому що ядро ​​не розроблялося з самого початку, маючи на увазі симетричну багатопроцесорність. Однак переважне ядро ​​означає щось інше. Традиційно контекст виконання змінювався лише тоді, коли ядро ​​повернулося до простору користувача. У попередньому ядрі нитка може бути попередньо випущена в середині запущеного коду ядра.
Йохан Мірен

3

Це не технічна відповідь, а історична відповідь на конкретне питання, поставлене ОП: "Що було причиною непередбачуваності старих ядер Linux?"

(Я припускаю, як пояснив @peterh у своїй відповіді та коментарях, що "непередбачуваність" ОП посилається на той чи інший факт, що всередині ядра (в API) може бути лише один користувальницький процес час та / або замок з великим ядром.)

Лінус Торвальдс зацікавився дізнатись, як працюють операційні системи, і як він навчився писати її. Його моделлю, базовим та початковим середовищем розробки був Minix - існуюча ОС для навчальних цілей (тобто не виробнича ОС), яка не була безкоштовною (як у відкритому коді, на той час - вона не була вільною, як у пиві, або).

Тож він написав ядро ​​без попередження (про великий замок ядра, про який згадували в інших відповідях), оскільки це так, як ви це робите, якщо хочете швидко запустити та запустити свою нову ОС для навчальних цілей: це набагато набагато простіше. Ядро для підтримки паралельного мультипрограммирования призначених для користувача програм і пристроїв досить важко - це вкрай складно зробити саме ядро одночасно.

Якби він знав, наскільки популярним / корисним / важливим став би Linux ... він, мабуть, зробив би це так само. (Тільки IMO, я поняття не маю, що він насправді думає.) Тому що ти мусиш піти, перш ніж ти можеш бігати.

І це залишалося надовго, тому що: а) ще багато було зробити, щоб зробити Linux таким, яким він є сьогодні (або навіть тим, що було тоді), і б) змінити це було б великим важким завданням (як пояснено в інших відповідях).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.