OSDev

для всех
Текущее время: 24 июл 2019, 09:29

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 102 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10, 11  След.
Автор Сообщение
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 16:30 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1109
Цитата:
Не согласен. Вытесняющая многозадачность - это противоположность кооперативной многозадачности.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 17:35 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
phantom-84 писал(а):
С обработкой прерываний справляется и одно ядро, при этом даже умудряется делать что-то сверх того)))

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

phantom-84 писал(а):
Прям как в винде.

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

phantom-84 писал(а):
Так я тоже думаю, что хуже, но не могу убедительно ответить на вопрос: "Почему хуже?"

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

phantom-84 писал(а):
2. Да, но требует уточнения: вы сами говорили, что однозначно нужно забирать тяжеловесный поток (высокоприоритетный). А вот если таковых нет, брать легковесный (один или даже несколько) или уходить в спячку, пока тебя не нагрузит и не разбудит другое ядро?

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

phantom-84 писал(а):
3. Требует серьезного уточнения. Ядро может и не само этим заниматься. Раз мы уже сошлись на том, что очередь выполнения для каждого ядра своя, это может сделать выводящее из ожидания высокоприоритетный поток ядро, который может быть закреплен и за другим ядром.

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

phantom-84 писал(а):
4. Да, только каковы критерии того, эффективнее перевести поток на другое ядро или проще его придержать на текущем ядре?

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

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 17:42 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 17:45 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1382
Yoda писал(а):
Уууу, кабы всегда справлялось, было бы просто супер :). А то зачем тогода Microsoft ввела понятие DPC и весьма жёсткие регламенты на время работы самого обработчика прерывания?


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 21:33 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1204
Yoda писал(а):
Уууу, кабы всегда справлялось, было бы просто супер :). А то зачем тогода Microsoft ввела понятие DPC и весьма жёсткие регламенты на время работы самого обработчика прерывания? В моей разработческой практике пришлось столкнуться с кучей драйверов написанных с наплевательским отношением к этим регламентам, в результате чего другая железка теряет свои данные.
Естественно, я имел в виду только первичную обработку прерываний. Если бы одноядерные системы не справлялись даже с этим, то они в принципе были бы ущербными.

Цитата:
Ну не только в винде. И винда всё же не самая плохая ОС :)
Ну и не самая хорошая, иначе зачем "все мы здесь сегодня собрались"? )))

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 22:06 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 26 июл 2011, 22:11 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1382
phantom-84 писал(а):
Цитата:
Ну не только в винде. И винда всё же не самая плохая ОС :)
Ну и не самая хорошая


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 27 июл 2011, 11:08 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 959
Откуда: Дагоба
phantom-84 писал(а):
Естественно, я имел в виду только первичную обработку прерываний. Если бы одноядерные системы не справлялись даже с этим, то они в принципе были бы ущербными.

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

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

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

SII писал(а):
Ну а почему б не попробовать определиться с тем, что именно в винде плохо и почему оно плохо?

А оно надо?

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 30 июл 2011, 11:45 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1204
Приятного уикенда.

Я писал(а):
Yoda писал(а):
Вот между классами есть вытеснение, т.е. задачи более высокого класса вытесняют более низкий класс, и то, я не стал бы полностью вытеснять интерактивные (в системах с пользовательским интерфейсом).
Во-во. Тоже интересный вопрос, не нужно ли оставить небольшую форточку при выполнении более приоритетных потоков для менее приоритетных, чтобы не перекрывать последним полностью кислород.
Все-таки хотелось бы узнать, у кого как это реализовано.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Планировщик
СообщениеДобавлено: 30 июл 2011, 16:33 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1087
Откуда: Балаково
phantom-84 писал(а):
Все-таки хотелось бы узнать, у кого как это реализовано.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 102 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10, 11  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB