phantom-84 писал(а):
С обработкой прерываний справляется и одно ядро, при этом даже умудряется делать что-то сверх того)))
Уууу, кабы всегда справлялось, было бы просто супер :). А то зачем тогода Microsoft ввела понятие
DPC и весьма жёсткие регламенты на время работы самого обработчика прерывания? В моей разработческой практике пришлось столкнуться с кучей драйверов написанных с наплевательским отношением к этим регламентам, в результате чего другая железка теряет свои данные.
phantom-84 писал(а):
Прям как в винде.
Ну не только в винде. И винда всё же не самая плохая ОС :)
phantom-84 писал(а):
Так я тоже думаю, что хуже, но не могу убедительно ответить на вопрос: "Почему хуже?"
Практический пример. Два ядра. В какой-то момент запускается куча процессов (кликнул пользователь мышкой где-то там), через две секунды все процессы завершили работу, осталось только два процесса и так случилось, что они оба на одном процессоре, а пользователь ждёт именно их завершения. Пусть накладные расходы (сугубо абстрактно!) на перенос с ядря на ядро составляют 1 секунду (в реале, конечно на порядки меньше!), а эти процессы работают вместе 20 секунд. В таком случае пользователь скрипит зубами на 9 секунд дольше, чем мог бы :)
phantom-84 писал(а):
2. Да, но требует уточнения: вы сами говорили, что однозначно нужно забирать тяжеловесный поток (высокоприоритетный). А вот если таковых нет, брать легковесный (один или даже несколько) или уходить в спячку, пока тебя не нагрузит и не разбудит другое ядро?
Брать следующий по приоритету поток, и так далее, пока вообще есть что брать. Например, на втором проце могут висеть один реалтайм поток и один интерактивный. Надо разгрузить второй проц, чтобы ему лучше работалось над задачей реального времени :) Даже пусть реалтайм+фоновый, или даже два фоновых – один фоновый процесс мог бы сколь-нибудь продвинуться, пока второй проц занят другим. Я считаю так, – брать имеет смысл
любой процесс, если он выполняется дольше определённого порога времени, который определяется накладными расходами на перенос.
phantom-84 писал(а):
3. Требует серьезного уточнения. Ядро может и не само этим заниматься. Раз мы уже сошлись на том, что очередь выполнения для каждого ядра своя, это может сделать выводящее из ожидания высокоприоритетный поток ядро, который может быть закреплен и за другим ядром.
ВСЕ ядра могут оказаться занятыми. Только одни ядра могут молотить низкоприоритетные задачи, в то время, как другое ядро будет кричать SOS! Т.е. заняться задачей по перераспределению может оказаться некому. Но балансировка нагрузки необходима.
Ладно, предлагаю сделать так. Выделяется небольшая глобальная область, где каждое ядро сохраняет некий предельно компактный дайджест о своей занятости, доступный для чтения другим ядрам. На основе этого дайджеста любое ядро в произвольный момент времени может принять решение о перераспределении нагрузки. Это могут быть как случаи с недонагрузкой так и с перенагрузкой.
phantom-84 писал(а):
4. Да, только каковы критерии того, эффективнее перевести поток на другое ядро или проще его придержать на текущем ядре?
Мне пока сложно придумать конкретные критерии. Ясно, что они должны основываться на следующих вещах: приоритет задачи, загрузка ядер и длительность выполнения задачи. Я думаю, что конкретные критерии лучше подобрать экспериментально.