Может ли ограничение потоков ОС одним процессором быть плохим?

Допустим, моя машина с Windows Server 2012 R2 имеет 8 логических ядер. Используя привязку потока/процесса, класс приоритета процесса и приоритет потока, я могу настроить 7 потоков приложений для работы на ядрах 1-7 и установить их уровень приоритета в режиме реального времени/критичный ко времени, чтобы они вытесняли все потоки ОС и работали на них без перерыва. ядра. Результатом этого должно быть то, что ОС может запускать потоки только на ядре 0 и делает это без каких-либо мешающих потоков приложений.

Если мое понимание сходства и приоритета верно и этот сценарий возможен, будет ли это проблемой для ОС? Будет ли затронуто какое-либо поведение системы? Достаточно ли одного ядра для ОС?

Это делается для того, чтобы исключить переключение контекста и обеспечить, чтобы в среде всегда были одни и те же 7 рабочих потоков, работающих параллельно без прерывания и без конфликтов кеша.


person Michael220    schedule 03.09.2015    source источник
comment
Это было бы очень плохой идеей. Все, что вы делаете, это отбираете выбор у планировщика. Это может иметь смысл, если вы знаете что-то необычное о своем приложении, чего не знает планировщик. Но, похоже, это не тот случай. Только один пример того, как это может быть отстойно, если эти 8 логических ядер реализованы на 4 физических ядрах, вы можете заставить единственные два потока, которые должны выполнять работу, застрять на одном физическом ядре.   -  person David Schwartz    schedule 03.09.2015
comment
Вы действительно измеряли производительность, когда делаете что-то подобное? И сравнил это с тем, как быстро все работает, когда вы этого не делаете?   -  person Andrew Henle    schedule 03.09.2015
comment
@AndrewHenle, я только настроил тестовую программу, чтобы убедиться, что могу ограничить ОС одним ядром. Я недостаточно знаю о внутреннем устройстве ОС, чтобы знать, смогу ли я безопасно запускать свой сервер в долгосрочной перспективе, поэтому я фактически не проводил никаких испытаний. Мое приложение — это сервер, который работает 24/7 и должен выдерживать высокую и постоянную нагрузку. Все темы всегда будут рабочими.   -  person Michael220    schedule 03.09.2015
comment
@DavidSchwartz, хорошая мысль. Затем я бы изменил сценарий на 8 физических ядер или что-то еще, что есть у машины. Мой сервер работает один, никаких других программ, кроме тех, что приносит с собой ОС, нет.   -  person Michael220    schedule 03.09.2015
comment
@ Michael220 - Тогда проведите сравнительный анализ и посмотрите, сможете ли вы превзойти планировщик ОС.   -  person Andrew Henle    schedule 03.09.2015
comment
@AndrewHenle, мой вопрос касается стабильности ОС в этом сценарии, а не производительности моего приложения. Я хочу убедиться, что не лишаю службы ОС необходимого процессорного времени. Мое предположение состоит в том, что одного ядра достаточно для всей работы, которую ОС выполняет за кулисами, особенно если на этом ядре не выполняются никакие потоки приложений.   -  person Michael220    schedule 03.09.2015
comment
Я считаю, что в принципе ОС должна быть стабильной, потому что подпрограммы прерывания ядра, APC и т. Д. Все равно будут работать - они всегда работают в контексте любого потока пользовательского режима, который оказывается живым, неважно, ваш ли это. или чужой. Насколько я знаю, нет способа привязать системные потоки к определенному ядру, так что это не должно быть проблемой. (Важные системные потоки в любом случае должны иметь более высокий приоритет, чем ваш.) И Windows по-прежнему отлично работает на одноядерных машинах, так что этот аспект не является проблемой.   -  person Harry Johnston    schedule 04.09.2015
comment
Однако вы можете столкнуться с проблемами из-за ошибок в драйверах сторонних устройств. Я не могу навскидку придумать какую-либо ошибку, которую вы могли бы запрограммировать в драйвере, которая срабатывала бы только в этом сценарии, но это не значит, что ее нет. Программисты очень изобретательны, когда дело доходит до новых и неожиданных ошибок. :-)   -  person Harry Johnston    schedule 04.09.2015
comment
Каковы последствия переключения контекста или промаха кеша в вашем приложении?   -  person Jason    schedule 04.09.2015
comment
Если это единственные потоки, почему вы думаете, что ОС не сделает это за вас? Зачем ОС перемещать ваши потоки, если они единственные заняты? ОС не дура. То, что вы предлагаете сделать, скорее всего, будет еще хуже.   -  person David Heffernan    schedule 04.09.2015
comment
@DavidHeffernan Приоритет в реальном времени должен быть достаточным намеком для планировщика, но промах кеша может по-прежнему влечь за собой неоптимальные затраты NUMA или неоптимальную связь между ядрами. и т.д... Измерение - единственный способ быть уверенным.   -  person Jason    schedule 04.09.2015
comment
@Jason, просто задержка, что делает это оптимизацией.   -  person Michael220    schedule 04.09.2015
comment
@DavidHeffernan, хорошая мысль, но если это все равно произойдет, то принуждение к этому не должно иметь никакого эффекта. Это гарантирует, что тривиальные фоновые задачи ОС не будут мешать коду приложения в случайное время, когда два потока ОС запланированы одновременно.   -  person Michael220    schedule 04.09.2015
comment
Дэвид Шварц и Дэвид Хефферман правы. Скорее всего, вы увеличите задержку для своего приложения (и снизите общую пропускную способность). Однако я не знаком с реализацией планировщика Windows, поэтому я бы рекомендовал протестировать и измерить конкретные вещи, которые вам нужно оптимизировать. Я думаю, что xperf или etw должны быть хорошими ресурсами для Windows. Вот еще один вопрос, который, возможно, стоит прочитать.   -  person Jason    schedule 04.09.2015
comment
@ Джейсон, спасибо за ссылку на этот вопрос, я не мог найти многого по своему конкретному вопросу, когда сначала искал. Ответ Сурта по-прежнему предполагает, что существуют ограниченные случаи использования, когда привязка к ядру может улучшить задержку. Думаю, мне просто нужно протестировать и настроить для моего конкретного приложения.   -  person Michael220    schedule 04.09.2015


Ответы (1)


Весь смысл планировщиков в операционных системах, которые являются очень активной областью исследований, заключается в том, чтобы создать иллюзию для каждого потока/процесса, что он получает все время процессора. Как отметил @David Schwartz, вы отказываете планировщику в возможности сделать это.

Так что да, это, вероятно, будет проблематично для ОС и поведения системы — система может быть не в состоянии своевременно реагировать на прерывания, а некоторые задачи, связанные с ядром, такие как запись на диск, будут отложены. Это, в свою очередь, может привести к потенциальной потере данных (в случае сбоя приложения/системы).

person tonysdg    schedule 03.09.2015
comment
да, дисковая активность - это то, что в основном приходит мне на ум. Я могу сказать, что мое приложение будет единственной запущенной пользовательской программой, и что я буду выполнять свою собственную буферизацию файлов (FILE_FLAG_NO_BUFFERING). - person Michael220; 03.09.2015
comment
Значит, одного ядра недостаточно, чтобы ОС могла обрабатывать прерывания и другие задачи, связанные с ядром? - person Michael220; 04.09.2015
comment
@ Michael220 Теоретически? Если ОС может работать на одноядерном однопроцессорном процессоре, то да, так и должно быть. На практике? Я предполагаю, что большинство современных операционных систем, включая Windows, в лучшем случае будут вялыми, в среднем не будут отвечать на запросы, а в худшем — необратимыми. Но единственный совет, который я могу дать наверняка, это совет, который однажды дал мне профессор — DTFE, ха-ха :) - person tonysdg; 04.09.2015
comment
чтобы получить лучший ответ, запускайте все подключения к серверу в потоках, которые являются объектами «пула потоков», и пусть планировщик беспокоится о том, какой ЦП использовать и как обрабатывать переключения контекста. Таким образом, сервер может обрабатывать тысячи подключений, тогда как предлагаемый метод может обрабатывать только 7 подключений. - person user3629249; 04.09.2015