OSDev

Противоположность кооперативной многозадачности это квантовая многозадачность в английских терминах Time slice.
Я лично останусь при своем мнении.

Уууу, кабы всегда справлялось, было бы просто супер :). А то зачем тогода Microsoft ввела понятие DPC и весьма жёсткие регламенты на время работы самого обработчика прерывания? В моей разработческой практике пришлось столкнуться с кучей драйверов написанных с наплевательским отношением к этим регламентам, в результате чего другая железка теряет свои данные.


Ну не только в винде. И винда всё же не самая плохая ОС :)


Практический пример. Два ядра. В какой-то момент запускается куча процессов (кликнул пользователь мышкой где-то там), через две секунды все процессы завершили работу, осталось только два процесса и так случилось, что они оба на одном процессоре, а пользователь ждёт именно их завершения. Пусть накладные расходы (сугубо абстрактно!) на перенос с ядря на ядро составляют 1 секунду (в реале, конечно на порядки меньше!), а эти процессы работают вместе 20 секунд. В таком случае пользователь скрипит зубами на 9 секунд дольше, чем мог бы :)


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


ВСЕ ядра могут оказаться занятыми. Только одни ядра могут молотить низкоприоритетные задачи, в то время, как другое ядро будет кричать SOS! Т.е. заняться задачей по перераспределению может оказаться некому. Но балансировка нагрузки необходима.
Ладно, предлагаю сделать так. Выделяется небольшая глобальная область, где каждое ядро сохраняет некий предельно компактный дайджест о своей занятости, доступный для чтения другим ядрам. На основе этого дайджеста любое ядро в произвольный момент времени может принять решение о перераспределении нагрузки. Это могут быть как случаи с недонагрузкой так и с перенагрузкой.


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Вытесняющая многозадачность -- противоположность корпоративной, как кто-то писал. Принципиальная разница между ними в том, что при вытесняющей многозадачности задачу (поток, процесс -- неважно, как назвать) "прогоняет" с процессора ОС по своему собственному волевому решению (на чём основанному, роли не играет), а в корпоративной задача уходит с процессора добровольно (либо переходя в ожидание чего-нибудь, либо с помощью специального системного вызова). Разделение времени (time slicing) -- это лишь один из видов вытесняющей многозадачности, основанный на том, что каждой задаче выделяется определённый квант времени, в течение которого она может непрерывно занимать процессор. Квантования времени может и не быть. Например, OS/360 могла быть сгенерирована как с квантованием времени, так и без оного, но она всегда была системой с вытесняющей многозадачностью (просто без квантования задачи вытеснялись исключительно на основе их приоритетов).

Это ввелка не Мыкрософт: механизм отложенной обработки пришёл в НТ из ВАХ/ВМС, а оттуда -- из РСХ-11. Был ли он где раньше -- мне неведомо. Ну а жёсткие рамки введены для того, чтобы система чрезмерно не тормозила с обработкой прерываний. Если б все разработчики драйверов следовали требованиям, было бы куда лучше, но увы...

Естественно, я имел в виду только первичную обработку прерываний. Если бы одноядерные системы не справлялись даже с этим, то они в принципе были бы ущербными.

Ну и не самая хорошая, иначе зачем "все мы здесь сегодня собрались"? )))

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

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

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

Естественно, именно первичную обработку я и имел ввиду. Надо спасаться от кривости написания именно первичной обработки в драйвере. DPC и лимиты времени – защита от потери данных со стороны авторов драйверов. Раскидывание по ядрам – со стороны ОС.


Каких именно?


А оно надо?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Приятного уикенда.

Все-таки хотелось бы узнать, у кого как это реализовано.

После недавних дебатов меня заинтересовал вопрос, как Windows экономит память, отводимую стекам ядра. Ответ оказался прост - она их выгружает (вычитал в литературе про состояние потока Transition - готовый с выгруженным стеком ядра). Понятно, что стек ядра можно выгружать не для любого потока.

Про "легковесные" потоки тоже думал. Мне такое может подойти только для "неубиваемых" потоков ядра, причем не всех. "Легковесность" может заключаться в сокращении объема памяти под стек с 12 до 4 кб (практически весь объем пойдет на структуру потока и резерв для обработки прерываний) и независимости от контекста процесса.

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