В чем была причина отсутствия преимуществ у старых ядер Linux?

15

Почему первые разработчики Linux решили реализовать не вытесняющее ядро? Это сохранить синхронизацию?

Насколько я знаю, Linux был разработан в начале 90-х, когда на ПК был один процессор. Какое преимущество дает не вытесняющее ядро ​​на таких ПК? Почему, однако, преимущество снижается за счет многоядерных процессоров?

Narden
источник

Ответы:

25

В контексте ядра Linux, когда люди говорят о преимущественном использовании, они часто ссылаются на способность ядра прерывать себя - по сути, переключать задачи во время выполнения кода ядра. Позволить этому случиться довольно сложно, что, вероятно, является основной причиной, по которой ядру потребовалось много времени, чтобы сделать его приоритетным.

Сначала большая часть кода ядра не могла быть прервана, так как была защищена большой блокировкой ядра. Эта блокировка постепенно устранялась из все большего и большего количества кода ядра, что позволяло параллельно выполнять несколько одновременных обращений к ядру (что стало более важным, поскольку SMP-системы стали более распространенными). Но это все еще не делало само ядро ​​пребывающим; это потребовало еще большей разработки, кульминацией PREEMPT_RTкоторой стал набор патчей, который в итоге был объединен с основным ядром (и в любом случае был способен опережать BKL). В настоящее время ядро ​​может быть сконфигурировано так, чтобы оно было более или менее выгружаемым, в зависимости от характеристик пропускной способности и задержки, к которым вы стремитесь; см. соответствующую конфигурацию ядра для деталей.

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

Стивен Китт
источник
11

Упреждающее ядро ​​означает только то, что Big Kernel Lock не существует .

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

Вопреки - в то время - широко используемому Win31. На Win31, если задача получила ЦП от «ядра», по умолчанию она должна была определить, когда вернуть управление операционной системе (или другим задачам). Если процесс не имел специальной поддержки для этой функции (что требовало дополнительной работы по программированию), то при выполнении все остальные задачи были приостановлены. Так работали даже самые простые приложения, интегрированные в Win31.

Упреждающая многозадачность означает, что задачи не могут распределять процессор так, как они хотят. Вместо этого, если их временной интервал истекает, ядро ​​отнимает у них процессор. Таким образом, в приоритетных операционных системах плохо написанный или плохо функционирующий процесс не может заморозить ОС или предотвратить запуск других процессов. Linux всегда был преимуществом для процессов пользовательского пространства.

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

Превентивное ядро ​​потребовало устранения этой большой блокировки ядра, т. Е. Монтирование и любые другие задачи для одновременной работы. Это была большая работа.

Исторически это было действительно актуально из-за растущей поддержки SMP (поддержка нескольких процессоров). В первый раз были действительно многопроцессорные материнские платы. Позже несколько процессоров («ядер») были интегрированы в один чип, сегодня действительно многопроцессорные материнские платы уже редки (как правило, в дорогих серверных системах). Также действительно одноядерные системы (где есть только один процессор с одним ядром) встречаются редко.

Таким образом, ответ на ваш вопрос не в том, «что послужило причиной отсутствия вытеснения», потому что оно всегда было вытесняющим. Реальный вопрос в том, что сделало упреждающее выполнение ядра действительно необходимым . Ответ за это: увеличение соотношения многоядерных, многоядерных систем.

Петер - Восстановить Монику
источник
Я на самом деле не понимал :( До версии ядра 2.4, только пользовательские процессы были вытесняющими, а ядро ​​не было вытесняющими. Как я уже отвечал кому-то раньше, я думаю, что причина была в том, чтобы сохранить работу по взаимоблокировкам синхронизации, которые могли случиться с вытесняющими реализация на одноядерный процесс. Как вы думаете?
Нарден
@ Я не знаю, где ты это читал. Примерно до версии 1.3 или 2.0 в пространстве ядра может быть только один процесс, даже если запущено несколько процессов. Это ограничение было устранено примерно с 2.0. Примерно до версии 2.4 существовала блокировка большого ядра (т.е. одновременное монтирование нескольких файловых систем не работало).
Петер - Восстановить Монику
@Narden Но это не совместная многозадачность, ни один процесс никогда не требовался, чтобы преднамеренно возвращать процессор в планировщик задач. Да, причина того, что BKL, вероятно, заключалась в том, что делать это правильно - огромная работа: 1) необходимо разделить блокировки 2) следует использовать структуры данных без блокировок, если это возможно 3) разделенные блокировки приводят к взаимоблокировкам / livelocks, это, как правило, особенно грязные, трудно исправляемые ошибки, все они должны быть найдены и исправлены 4) все драйверы должны быть перенесены на изменения в ядре API ядра.
Петер - Восстановить Монику
Я читал его, пока искал ответ, и он также приводится в качестве информации в курсе, который я беру, под названием «Операционные системы».
Нарден
1
Большая блокировка ядра не позволяла другим потокам входить в ядро ​​во время его работы в ядре. Был разрешен только один поток, поскольку ядро ​​изначально не проектировалось с учетом симметричной многопроцессорности. Однако упреждающее ядро ​​означает нечто иное. Традиционно контекст выполнения изменялся только тогда, когда ядро ​​возвращалось в пространство пользователя. В приоритетном ядре поток может быть прерван в середине выполнения кода ядра.
Йохан Мирен
3

Это не технический ответ, а исторический ответ на конкретный вопрос, заданный ФП: «В чем причина отсутствия преимущественного отношения в старых ядрах Linux?»

(Я предполагаю, что, как объяснил @peterh в своем ответе и комментариях, под «не преимущественным преимуществом» OP ссылается либо на то, либо на то, что внутри ядра (в API) может быть только один пользовательский процесс в время и / или Большой замок ядра.)

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

Поэтому он написал ядро ​​без упреждения (Big Kernel Lock упоминается в других ответах), потому что именно так вы и делаете, если хотите быстро запустить и запустить новую ОС в образовательных целях: в этом случае все гораздо проще. Ядро для поддержки одновременного многопрограммного программирования пользовательских программ и устройств достаточно сложное - сделать ядро ​​одновременно очень сложным.

Если бы он знал тогда, насколько популярным / полезным / важным Linux станет ... он, вероятно, сделал бы это так же. (Только для ИМО, я понятия не имею, что он на самом деле думает.) Потому что ты должен идти, прежде чем сможешь бежать.

И так продолжалось довольно долго, потому что а) нужно было сделать много другой работы, чтобы сделать Linux тем, чем он является сегодня (или даже тем, чем он был тогда), и б) изменить его было бы серьезным трудным делом. (как объяснено в других ответах).

davidbak
источник