The Wonderful World of Linux....

Помнится перед выходом 2.4 тоже было "Wonderful World of Linux", а какие были кривые первые ядра 2.4...

http://www2.gamesville.lycos.com/html_poke/poke_penguin.htm

чудесный мир линукса :)))

Вот это я не понял :(

On major internal change present in the 2.6 kernel that should not be understated is that the kernel itself is now preemptible. In all previous versions of Linux, when the OS is currently doing something in the kernel, it can't be interrupted (and on multi-processor machines, this was true on a per-CPU basis.) As of Linux 2.6, the kernel now allows itself to be interrupted mid-task so that user applications can continue to run even if the kernel is doing something complicated. (In order to avoid the obvious race conditions that this can cause, the kernel does have certain sections of the code locked so that they can not be interrupted while in progress.) The primary benefit of this change is that interactive performance (for desktop users, for example) has been given a boost and so the system will "feel" faster for things like user input.

Часть ядра может быть временно выгружена из памяти или приостановлена что бы дать работать user-скому процессу ????

МОЖЕТ КТО ПЕРЕВЕДЕТ НОРМАЛЬНО ?

ИМХО речь идет не о выгрузке из памяти а о переключении контекста. В не-preemptible ядре задачи ядра имеют абсолютный приоритет, в preemtible - нет.

... волшебный мир Linux 2.6 ;)

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

главная фича, что я увидел - теперь модули называются побздишному, то есть .ko вместо .o . Пральным путём идут, так лет через 10 они наконец-то смогут бздю догнать

2anonymous (*) (2003-07-16 18:46:40.254564): Полностью вытесняемое ядро.

Ядро - НЕ процесс. Процесс может находится в 2 состояниях: ядерном и юзеровском.

Раньше (в Линухе) процессы в ядерном состоянии рвать было нельзя. То есть во время системного вызова планировщик не мог прервать один процесс и запустить другой. И это было правильно (IMHO), ибо в состоянии ядра работает ядерный код, который должен быть достаточно умным, чтобы не монополизировать процессор.

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

M$ в свое время вставила к себе эту феньку, "штоб було" (она как дитя малое - все в рот тянула) и потом раскрутила ее как нечто современное, такое, без чего ОС - отстой. Теперь подавляющее большинство пипла так считает, и отказывается хавать продукт без подобной феньки.

Линус долго сопротивлялся, но в последние годы устал и - ... Короче, теперь оно тама.

А чем плохо что оно там? preemtive kernel фича опциональная и включается при сборке ядра.

anonymous (*) (2003-07-16 23:25:35.306276):
> А чем плохо что оно там?
Поднятым ажиотажем.

> preemtive kernel фича опциональная и включается при сборке ядра.
Почти уверен, что все ведущие дисрибуторы поднимут ее в default kernel.
В результате Линух станет тормозить, как НТя. Пойдут новые (написанные
для M$) тесты, в которых НТя уделает Линух, после чего пойдут
рекомендации ведущих консультантов:
1. Не ставить тормозной Линух на предприятиях,
2. Всем программить под замечательный Win32.
3. OpenSorce - давить на корню, как мешающий M$ неусыпно заботиться о
повышении жизненного уровня трудящихся.

Сама же по себе фенька, безусловно, полезна - именно как опциональная.

> ибо в состоянии ядра работает ядерный код, который должен быть достаточно умным, чтобы не монополизировать процессор

Это как? :-]

> Почти уверен, что все ведущие дисрибуторы поднимут ее в default kernel.
> В результате Линух станет тормозить, как НТя. Пойдут новые (написанные для M$) тесты, в которых НТя уделает Линух, после чего пойдут рекомендации ведущих консультантов:
> 1. Не ставить тормозной Линух на предприятиях,
> 2. Всем программить под замечательный Win32.
> 3. OpenSorce - давить на корню, как мешающий M$ неусыпно заботиться о повышении жизненного уровня трудящихся.

4. Москву переименовать в Нью-Васюки.

anonymous (*) (2003-07-16 23:43:53.931712):
> Это как? :-]
Чем Инго занимался.

> главная фича, что я увидел - теперь модули называются побздишному, то есть .ko вместо .o

как много значит название.... :-))

>Возможность рвать процессы в ядерном состоянии - фича, характерная для 
>систем реального времени. Вообще-то, она снижает общую 
>производительность системы. 

...Но уменьшает время отклика (для интерактивных процессов в часности)
Как я понял, это заточка под десктопа. 

PS: для 2.0.x кстати был QNX-style шедулер - ну очень заметно улучшал
отклик на слабых машинках ...

XFree86 for FreeBSD/amd64

>Возможность рвать процессы в ядерном состоянии - фича, характерная для систем реального времени. Вообще-то, она снижает общую производительность системы.

Системы реального времени здесь не причем,

preemtive kernel фича позволяет ядру планировать исполнение кода

в драйверах, это ее основное назначение, а производительность

системы это наоборот повышает.

Кстати ядро BSD/OS 5 это умеет делать, из свободных

юнихов пока никто

>preemtive kernel фича позволяет ядру планировать исполнение кода
>в драйверах, это ее основное назначение, а производительность
>системы это наоборот повышает. 

В ядре приходится делать дополнительнную синхронизацию  - "невытесняемые  участки кода" - а любые  дополнительные локи сажают производительность ...

2DieHard >Возможность рвать процессы в ядерном состоянии - фича, характерная для >систем реального времени. Вообще-то, она снижает общую >производительность системы.

И чо здесь хорошего? Опять появятся баги. Ничего личного. Все написал нормально (отнолсится к разработчикам). Тока нафига оно в ядре? Так мона и системные вызовы ядра того... ну урюхать систему. В линухах ведь что подкупает? Лучшая надежность чем в M$. Ну и модульность.

Sun-ch (*) (2003-07-17 12:46:18.661583):

> Системы реального времени здесь не причем, > preemtive kernel фича позволяет ядру планировать исполнение кода > в драйверах, это ее основное назначение...

Сие высказывание противоречит тому, что мне известно на этот счет из многократно повторенных за последние годы дискуссий.

Противоречит это высказывание и известным мне фактам. В частности, знаменитый Лововский патч пришел из Монта Висты, которая как раз двигала Линух в сторону RealTime.

Планировщик ничего не знает о драйверах, поэтому планирование исполнения кода драйвера сторонним планировщиком может в лучшем (недостижимом) случае НЕ понизить общую производительность. Повысить ее оно не может по определению: самый криво написанный драйвер не сможет выполнить свою работу быстрее от того, что его постоянно перебивают, и суммарное время, проведенное в кернел спейсе этим драйвером, никак не уменьшится от перебивания его планировщиком.

Впрочем, я не считаю себя экспертом в этой области. Полагаюсь на прочитанную литературу, учебники и дискуссии на форумах.

sS (*) (2003-07-17 10:45:29.097107):
> ...Но уменьшает время отклика
Правильно!

Хорошо известно, что требования улучшения bandwidth и latency друг
другу противоречат.

> Как я понял, это заточка под десктопа.
А это - известная маркетинговая песенка M$. Когда они раскручивали сию
феньку как суперпрогрессивную, они это и придумали.

Вообще-то, это не совсем так. В микроядерных системах это вообще совсем
не так. Разумеется, разрешив рвать драйверы, ты получишь уменьшение latency
на слабых машинках - но не проще ли (теоретически) для слабых машинок
использовать соответствующие драйверы?