>anonymous (*) (2002-02-16 12:52:52.0)

>ут уже было высказано точка зрения, что микроядро - это аппаратно зависимая часть операционки. Пишится на ассемблере под конкретный процессор. Реализует минимум системных вызовов...
Кроме системных вызовов - есть 99,9% аппаратнозависимости. В этом случае вы подвели "линукс == микроядро"... :):):) - там как раз почти вся аппаратнозависимость и сосредоточена...

>Вытесняемое ядро - это когда в самом ядре одни задачи могут урвать часть ресурсов у другогих задач
Вообще-то тут очень часто мелькает термин "вытесняемое ядро" - это куда вытесняемое? и когда?... Вытесняемое на дискетку? или ещё куда? :):):) Куда вы собрались вытеснить его - не очень понятно, я лично знаю вытесняющую и не-... многозадачность, но при обоих ядро на месте остаётся... :):), как ни странно... В самом ядре "задач" нет, задачи могут обратиться К ядру.... (хотя этот аспект и спорный - но это моё мнение, что процессы в с-е ядра не являются просто прикладными процессами). А насчёт "урывов" у друг друга - это рассадник вирусов... Либо есть чёткая централизация и этим домиком для глюков управляет ядро, либо нет - в этом случае переходим к чему-то, где вместо ядра io.sys и ...os.sys

>По-моему, лучше будет всем, если Линукс станет микроядерным.
Это не факт... Может "да". а может "нет" - не нравится монолитный линукс, ставь микроядерный мах или дарвин..

Кстати, чтобы не было каши, уважаемые, ядро может быть монолитным или микро, а в любом из них может быть реализована вытясняющая многозадачность, или не-..., или обе вместе...:)

А почему бы вам всем вместе не перестать говорить про вытесняющую многозадачность и микроядра ? Вы этим народ путаете, да и оффтопик это, т.к. это разные понятия с preemptive kernel'ом.

Итак, с третьего захода, после тщательного анализа баталий Дие-Харда+Анонимуса вс Мудвин+Чучело я таки разобрался о чем речь :-)))) Ну и конечно благодоря Проффу :-))))

2 Дие-Хард. Имхо Чучело на начальном этапе дисскусии не очень понимал о чем речь, и то, что он тактично обошел молчанием ваши гипотезы относительно этого вопроса и довольно долго не казал носа по ходу дисскусии косвенно подтверждает мое предположение :-)))) Ну а Мудвин просто не понимал о чем речь. Имхо, более продуктивно было бы просто ему ( а заодно и мне :-)))) ) разъяснить о чем речь, как это чуть позже сделал Профф, а не пытаться ему объяснить, что он ошибаеться, так как если человек ошибаеться, но не знает об этом, указать ему на это довольно не просто :-)))))

2 Мудвин. Можно было заметить, что у вас с Дие-Хардом наблюдаеться взаимное непонимание (в данном случае по причине придания терминам разного значения). В таком случае вероятно целесообразние было бы выяснить значения терминов, хотя бы что бы убедиться, что непонимание не вызвано таким распространенным случаем.

2 Чучело. "и так дайхард признался что он тут не специалист," На вашем месте, я бы не стал заострять на этом внимание :-))))) Дие-Хард в этом впоросе проявил куда как большую осведомленность нежели вы :-)))) И кстати, если вы сказали не очень умную вещь, которую кто-то принял за слишком умную - это не повод делать ноги в кусты :-)))))

2 Алл. Ну а теперь, раз пошла такая пьянка, хотелось бы узнать, чем "вытесняющая многозадачность" отличаеться от "невытесняющей" ???? Можно без исторических справок и комментариев, а то кто-нибудь опять внесет в обсуждение свежую струю :-))))) Наподобие того, как это сделал ув. тов. Антихрист :-)))))))))))))))) А то я знаю о ней лишь по рекламе от M$ (правда, я думаю, Дие-Хард имел в виду другую рекламу :-))))) и она у меня устойчиво ассоциируеться с "kernel32.dll -> системе существенно не хватает ресурсов" :-))))) Я конечно, понимаю, что это шаг вперед по сравнению с тем, как strippoker.exe в свое время "вытеснял" nc/vc/dn и т.п. :-))))), но немного не понимаю, чем она лучше той "невытесняющей" многозадачности, что уже есть в Линухе и зачем она там нужна ?????? :-))))))))

Что то мне все эти разговоры сильно напоминают 80(конец)-90 годы в разрезе WIN/OS. Было в свое время такое амер. СП M$ и IBM, о святые времена Win1.0-Win3.x. Так вот эта команда работала над "серьезным" десктопом аля Форточки по виду и VMS in vitro. Что из этого получилось большинство из нас (старшее поколение :-))знает, для молодых скажу WINNT3.x и OS/2 3.x, так вот, самое интересное, они (СП) разбежались, именно тогда, когда собирались работать на ядром с "вытяснением несистемных процессов"(пользуюсь терминологией тех дней, из пресс релиза тех дней (может конечно и перевод кривой)). У вин 3.х как помнится были проблемы, на а пол оси были в этом плане существенне прочнее.Да и более поздие системы означенных фирм вели себя совершенно по разному, опять же в плане обсуждения. И вообще, сейчас уже не вспомню, но на Veronica, был в свое время такой поисковый инструмент была куча ссылок по этой теме, в т.ч. и серьезные вещи, надо бы поискать в архиваю у себя на диска, там были и полные описания терминологии.

Каким образом решается невытесниловка?
ИМХО, просто ядро не прерывает приложение пока оно само не свернётся. Если точнее - пока не скажу, ковыряюсь в исходниках - а так как ветку 2.5 до сего момента не трогал - то многого недопонимаю...
Чем это грозит? Могу только предполагать, что приложение, в силу каких-то обстоятельств, идентифицируемое как невытесняемое будет выполняться в наилучших условиях - нет лишних "хлопаний" контекстами, нет лишних переключений... Но пока это всё зело непонятно....

2LamerOK: по-моему просто сам термин "вытесняющая многозадачность" применительно к этому треду надо выкинуть на помойку ибо только флейм порождает и имеет устаканившиеся в народе ассоциации с вытеснением одной задачи для отдавания кванта времени другой. это реализовано в почти любой современной ОС. в некотором смысле "невытесняющая многозадачность" или, иначе "кооперативная многозадачность" это то, что имело место например в win 3.1[1] или, в извращенной форме в виде досовских резидентов, то-есть если задача не отдала управление то опаньки, и система не может забрать у нее проц, хоть вся эта байда в случае Win 3.x и работала в защищенном режиме.

это было лирическое вступление про термины :)

так вот, в данном треде судя по топику, должно было обсуждаться перераспределение времени между процессани в ядре, то-есть если один процесс, например дисковый ввод-вывод ждет ответа диска, то, по идее ничего не мешает(теоретически) отдать это время другому подпроцессу ядра для обслуживания например сетевушки или еще чего.

в микроядре это реализуется есстественным способом --- HDD drivers & NIC drivers это 2 разные задачи которые рулятся планировщиком и соответственно нету вообще вопроса об отбирании времени у одного и отдаванию другому.

в монолитном ядре все плохее :) так-как нету общего механизма переключения в другой контекст внутри ядерного процесса, это понятно? :)

вот об этом весь спор и, на мой взгляд, здравые рассуждения Die-Hard про интерактивность vs. лишние копирования/переключения контектса и соответственно общая производительность ядра :)

может быть несколько сумбурно и очень упрощенно, но поправьте если что переупростил :)

надеюсь хоть что-то прояснил.

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

>в некотором смысле "невытесняющая многозадачность" или, иначе "кооперативная многозадачность" это то ... если задача не отдала управление то опаньки
Ну в таком случае в Линухе относительно юзер-спейс процессов действует вытесниловка ???? Я так понимаю, что такая "кооперативная многозадачность" вообще не есть многозадачность, если ядро не может прервать процесс произвольно. И мне казалось что разница между виндовой "вытесняющей" многозадачностью и линушной заключалась в алгоритмах прерывания процесса и распределения процессорного времени. Или же разницы нет вообще никакой и линух только силен более или менее здравым шедулером ??? Или же он и им не слиен :-)))), и дело вобще только в том, что у виндов ядро кривее ??? :-)))))))))

> в извращенной форме в виде досовских резидентов
Ну это уж в ОЧЕНЬ извращенной :-)))))

>, в данном треде судя по топику, должно было обсуждаться перераспределение времени между процессани в ядре
Ну это то я понял :-))))) Просто хотелось заодно пофлеймить и на тему многозадачности в юзер-спейс процессах :-))))))))

>в монолитном ядре все плохее :) так-как нету общего механизма переключения в другой контекст внутри ядерного процесса, это понятно? :)
Это то понятно, но если ядро - это всего лишь обработчики прерываний и написаны они не через одно место, то по идее им должно быть пофигу на контекст ? Дернуло прерывание - сделал что надо и пошел дальше спать :-)))) Я правда не силен в ядреных архитектурах и может сморозил глупость... :-)))))))

>а всяких личностей ... повбывав-бы.
Ну они ж не со зла :-))))))))))

2anonymous (*) (2002-02-17 03:50:28.0):
> так вот, в данном треде судя по топику, должно было обсуждаться перераспределение времени
> между процессани в ядре, то-есть если один процесс, например дисковый ввод-вывод ждет ответа
> диска, то, по идее ничего не мешает(теоретически) отдать это время другому подпроцессу ядра
> для обслуживания например сетевушки или еще чего.
Нет.

То, что ты описываешь, и есть "невытесняющая многозадачность". Она
в Линуксе давно реализавана (я про ядерный контекст).

А речь шла о том, чтобы ПРИНУДИТЕЛЬНО выкидывать процессы, выполняющиеся
в ядерном пространстве.

При етом НТ вроде и не RTS, для RTS много других фич нана

Я не должен иметь малое время ответа, а должен иметь его предсказуемым.... Интересна как ето скажется на надёжности системы ведь теперь юзерский працесс смогет вытеснить ядро:) не привратится ли нормальная ОСь в поганую ОСь и такую же RTSОСь

Ядро не должно вытесняться процессами и всё тут

за каким ето на сервере нана? На счёт микро ядра Линус помнится очень нелицеприятно отзывался о Mach и MacOS X.... что мнение его так резко изменилось? Я вообщето из другой песочницы мне всёравно что будет в 2.5 но Ваши рассуждения преймуществах вытеснения ядра на сервере интересны:) Вы чтоли доводите сервера до 100% загрузки:)

Области применения систем реального времени

Тут был разговор о скорости

1) когда нужно обработать большой объём данных на предельной скорости имеющегося оборудования ниокаких сях и тем более ОСях не может быть и речи Такие задачи встречаются например в Радиолокации Одина знакомая девушка щаз как раз програмит *процессорную Sharkовскую доску и ей не хватает нескольких тактов процессора для завершения обработки в заданное время при том что применяется специально разработаный алгоритм и всё кодируется на ассемблере с жуткой ручной оптимизацией так что о применении хотябы просто софрта написаного на С с любой оптимизацией не может быть и речи

2) С применяются когда нужно обеспечить

а) сохранение кода - то есть код написаный для одного контроллера должен работать и на остальных аналогичных (в случае ассемблера часто его придётся переписывать) то бшь портабельность

б) Увеличить скорость и уменьшить стоимость разработки

в) не критична скорость и стоимость конечного продукта (малая серия)

если одно из стребований в в) не соблюдается то всё пишется на ассемблере (требования по скорости обработки данных или огромные серии - в последнем случае стоимость разработки не критична но на конечном устройстве нуна экономить каждый цент)

3) Системы реального времени

а) когда нужно ещё более увеличить скорость разработки б) когда совсем не критична производительность конечного устройства в) когда не критична стоимость конечного устройства г) когда необходимо обработать большое множество независимых потоков входных данных и в силе пункты а б и в иначе придётся писать всё (включая планировщик итп на ассемблере)

Итак с областью применения разоюрались... теперь одно маленькое замечание по всем пунктам - В БОЛЬШИНСТВЕ встраиваемых приложений очень важна надёжность и даже применяется (в отдельных случаях) резервирование... Как видите в области применения Систем Реального Времени время отклика хоть и должно быть известно но не ставится в такие жёсткие рамки как во "м и тем более !ом случае но надёжность ето самое главное во всех них и жертвовать ей ради небольшого прироста производительности нет смысла У меня не должно быть ситуации когда криво написаный процесс может повлиять на ядро мало того мне интересно а как ядро которое "вытеснено" процессом сможет прервать его в системной фазе исполнения - а ето одно из главных требований ибо время отклика должно быть ИЗВЕСТНО как можно более точно.

Мало того в случае применения

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

вот что интеремно, кто-нибудь использовал этот патч? использую ~3 месяца.

http://www.tech9.net/rml/linux/

Хотелось бы добавит своих пару центов
(а точнее не совсем своих) центов в
определение "preemtable kernel".
Дабы не вносить путаницу переводом,
прилагаю оригинал:

Preemtable kernel - The kernel can be
in the middle of a system call and be
preemted. The preemption could cause
a context switch that causes an entirely
new thread of execution inside the kernel.

Также, вот еще понятие, которое не следует
путать с вышеуказанным:

Pageable kernel - Part of the the kernel
is pageable.

Определения взяты из AIX Kernel Internals
(ядро AIX preemtable и pageable).

Илья.

2ZOD:
В ответ сразу на все, тобой написанное:
> Интересна как ето скажется на надёжности системы ведь теперь юзерский
> працесс смогет вытеснить ядро:)
Похоже, ты не очень себе представляешь, что такое ядро, и кто кого должен
вытеснять :).

Ты все правильно говоришь про Real Time. Действительно, важна не скорость
отклика, а предсказуемость.

Именно поэтому и разрабатывается возможность в любой момент прервать
ядерный вызов. Даже ценой потери общей производительности. Чтоб гарантированно
откликнуться в заданный промежуток времени.

> интересно а как ядро которое "вытеснено" процессом сможет прервать его в
> системной фазе исполнения
Ты понимаешь, что ядро - это НЕ процесс?
Ты понимаешь, что за циферки тебе выдает команда time? Типа
real 0m3.140s
user 0m0.030s
sys 0m0.010s
Что такое "sys"?

Или я тебя не понимаю?

2anonymous (*) (2002-02-18 07:44:48.0): а subj как раз про этот патч. :)

ZOD понимает что ядро ето не процесс

2Die-Hard

sys время реакции ядра.

ZOD нарочно написал про область применения Систем Реального Времени и хочет узнать что сдесь обсуждается RTS или обычная ОСь. ZOD не видит необходимости включать ету опцию нигде кроме как в описаных им в постинге про RTS случаях. ZOD согласен чта спорол чушь про вытесненное ядро ибо плохо понимает как работает фича которая прерывает процесс в системной фазе исполнения.

2ZOD (*) (2002-02-19 02:35:16.0):
> sys время реакции ядра.
ZOD плохо говорить Русский, AFAIU.
Это время, которое процесс провел в режиме ядра ("в системной фазе исполнения")

> как работает фича которая прерывает процесс в системной фазе исполнения.
8-0?
Die-Hard тоже не понимает, а что тут непонятного.

> ZOD не видит необходимости включать ету опцию нигде кроме как в
> описаных им в постинге про RTS случаях.
Ну, дык она и разрабатывалась для этого! Именно для того, чтобы включать
"ету опцию ... в описаных" ZOD'ом случаях. А они МОГУТ быть в
embedded ситуациях использования Линуксового ядра, что имеет место быть
исторически, да и, вообще, RT Линукс ел, есть и будет есть. Хорошо ли это,
плохо ли - судить не берусь по причине далекости от RT.

Два "Но".

1 - многие считают, что десктоп должен работать в RT режиме. И радуются феньке.
А некоторые из присутствующих уверяют даже, что и WEB серверу без нее - никуда!

2 - причина этого IMHO достаточно банальна.
При разработке NT M$ вставляла в нее все, что могла, просто так, "шоб булО".
Как ребенок маленький, все в рот тянет. Вдруг пригодиться? Спи... короче,
позаимствовали почти все эппловские наработки, все, что в юниксе модного нашли,
у IBM по карманам пошарили (чего только одно название NTFS стОит! Сейчас бы их
точно на бабки поставили, но в те времена, типа, они с IBM дружили и считали,
что все у них общее), и т.д. Ну, и RT фичи "до кучи".

Получился ТАКОЙ крокодил, что не заработал. Пришлось срочно задний ход давать.

Получившийся гибрид противоречит не только основам построения ОС, но и здравому
смыслу (чего только стОит ГУЙ в ... микроядре!).Зато в нем ВСЕ есть! Самое
передовое!

Осталось убедить рынок, что так оно и есть.

Что они и проделали.

И теперь все знают, что ядро должно быть preemptible, а иначе это - отстой,
прошлый век и работать на таком просто невозможно.

ZOD раньше тоже верил в сказки про то что

NTFS - ето переделаный HPFS - теперь уже не верит.... ZOD на полуоси собаку сьел в своё время и досих пор считает что ето самая десктопная система была а по перспективам и есть.... Он кажется на компьютерре или опеннете ещё спорил по етому поводу но там его переубедили... Да Алгоритмы одинаковые.... Да очень похоже и номер одинаковый тем не менее код микрософтовцы писали сами хотя общая концепция и стырена..... но не стырено несколько хороших фич типа расширеных атрибутов благодаря которым в ПолуОСи небыло никаких Desktop.ini

Тперь касательно линухового ядра ZOD мог и ошибиться - Баха он читал года полтора назад... тем не менее ZOD считает что вся прелесть юникса заключается в надёжном ядре которому побарабану до любых кривописаных процессов... ZOD считает что ядро должно быть по Баху и работать в привилегированом режиме и никем не вытесьняться.... Он даже против модулей ядра в том случае если их поставляют сторонние производители......

так народ берусь я за разборку полетов :))))))))) надо посмотреть что, где и когда :)))) было, есть и будет :)))

2 anonymous (*) (2002-02-11 23:03:20.0) aka Nick

>Смотрю я на трэд, и не знаю, плакать мне или смеяться. Ни одной >конструктивной мысли. Что здесь все разработкой ядра занимаются? Или >просто общения не хватает? 2.5 еще настолько сырое, что ставить его >на домашнюю машинку (или тем более на рабочую) - самоубийству >подобно. Причем, спешу заметить, это еще только 2.5.4, а не скажем >2.5.135. Т.е. до стабилизации еще ух как далеко. И обсуждать - плоха >фича или хороша - тоже рано. Вот выйдет 2.6.0-rcX какой нибудь, вот >там и посмотрите. И ручками пощупаете. Или что, мы тут сейчас решим >- это плохо (хорошо) и сразу большой дядя Линус нас послушает? Не >смешите мои коленки. Будет стабильное ядро - будут тесты.
>Так что обсуждать здесь особо и нечего.


Поставил себе вчера 2.5.5 (до этого стоял 2.4.17) на домашний комп и как-то до сих пор жив ;-). Все грузится, все проги запускаются и пашут, интернет работает, еще ни разу ни одна прога, которую я юзаю не упала, иксы не вылетали. Прирост от вытесняемого ядра на глаз не заметен, но distributed.net стал считать на 2 kkeys/s быстрее :)). Так что, уважаемый, в другой раз сначала сам попробуй поюзать, а потом уже заявляй: "сырое", "самоубийство", если не хочешь полным ламером выглядеть.

2 anonymous (*) (2002-02-11 23:03:20.0) aka Nick

>Смотрю я на трэд, и не знаю, плакать мне или смеяться. Ни одной >конструктивной мысли. Что здесь все разработкой ядра занимаются? Или >просто общения не хватает? 2.5 еще настолько сырое, что ставить его >на домашнюю машинку (или тем более на рабочую) - самоубийству >подобно. Причем, спешу заметить, это еще только 2.5.4, а не скажем >2.5.135. Т.е. до стабилизации еще ух как далеко. И обсуждать - плоха >фича или хороша - тоже рано. Вот выйдет 2.6.0-rcX какой нибудь, вот >там и посмотрите. И ручками пощупаете. Или что, мы тут сейчас решим >- это плохо (хорошо) и сразу большой дядя Линус нас послушает? Не >смешите мои коленки. Будет стабильное ядро - будут тесты.
>Так что обсуждать здесь особо и нечего.


Поставил себе вчера 2.5.5 (до этого стоял 2.4.17) на домашний комп и как-то до сих пор жив ;-). Все грузится, все проги запускаются и пашут, интернет работает, еще ни разу ни одна прога, которую я юзаю не упала, иксы не вылетали. Прирост от вытесняемого ядра на глаз не заметен, но distributed.net стал считать на 2 kkeys/s быстрее :)). Так что, уважаемый, в другой раз сначала сам попробуй поюзать, а потом уже заявляй: "сырое", "самоубийство", если не хочешь полным ламером выглядеть.

2Shrike
И как? Еще жив? Файловая састема не побэдилась? Или не на IDE живешь?

2ShadowJack

Жив. Не побэдилась. На IDE. ;-)))