Почему современные приоритетные многозадачные ОС зависают при загрузке процессора?

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


Я не использую другие ОС достаточно часто, чтобы судить, но, конечно, во всех версиях Windows операционная система может быть запущена, когда приложения подключаются к ЦП. Понятно с ранними версиями, с совместной многозадачностью.

Однако, с преимущественной многозадачностью, разве операционная система не должна ставить себя и свой графический интерфейс на более высокий приоритет, чтобы оставаться отзывчивой, даже когда пользовательские приложения запрашивают полную загрузку ЦП? В конце концов, ОС не нужно выдавать какие-либо временные интервалы. В большинстве случаев меня не волнует, что приложение, которое потребует минут процессорного времени, откладывается на несколько микросекунд, чтобы графический интерфейс ОС мог реагировать на ввод.

Иногда это помогает установить процессы с высоким ЦП на более низкий приоритет, возможно, потому что это позволяет другим приложениям с низким ЦП, с которыми я взаимодействую, быть более отзывчивыми, создавая впечатление более отзывчивого общего опыта. Или приоритет приложения действительно влияет на его взаимодействие с процессами ОС?

Я видел это много раз, когда у меня было достаточно физической памяти без использования жесткого диска. Похоже, что использование процессора является основным непротиворечивым элементом, когда флаг ОС.

Контрпример: часто, когда система почти полностью зависла, мышь остается отзывчивой. Таким образом, ОС защищает эту часть себя от некоторых проблем. Точно, как это отдельный вопрос, я просто поднять его в качестве примера.

5 ответов

Единственные вещи, которые действительно могут привести к зависанию одной из "современных многозадачных ОС":

  1. аппаратный сбой
  2. Процессор застрял в драйвере устройства (из-за 1 или плохого программирования)
  3. фатальное исключение в драйвере устройства или другом коде ядра (из-за 1 или плохого программирования)

Операционная система в многозадачной ОС всегда отключает задачу, когда заканчивается ее временной интервал. Однако, если программа предназначена для реагирования на ввод пользователя, но не во время ее временного интервала, то ошибка в программе

Скорее всего, оболочка не отвечает. В Windows это explorer.exe, Вы можете попробовать следующее:

  • альтернативная оболочка Windows (Litestep и т. д.)
  • убить все через explorer.exe taskmgr.exeзатем запустите cmd.exeи делай свои вещи через командную строку. Или запустите небольшую программу, предназначенную для запуска других программ.

explorer.exe это одна из тех программ Windows, которые сильно разбиты на компоненты, в которые можно зацепиться. Вот и посмотри как дела без этого.

Попробуйте Linux. Если вы на самом деле собираете ядро, вы можете указать временной интервал. Также вы можете увидеть эффект preempt. Срез времени в 1000us лучше, если вы создаете сервер, на котором (вероятно) не будет беспокоиться об интерфейсе пользователя (но он все равно будет превентивной многозадачной ОС). С другой стороны, 100us приведут к чрезвычайно отзывчивой системе. Большинство дистрибутивов имеют 100us на своих настольных ОС, что означает, что даже если мой ЦП на 100% использует загрузку на всех ядрах, мой пользовательский интерфейс все еще отзывчив (вы можете попробовать).

User-mode applications generally can't slow down your OS's GUI. However, the situation isn't as clear-cut as it seems. There isn't a single user-mode application that is 100% user-mode, either because of system calls (notably the file system) or because of virtual memory mapping.

In most cases, the OS isn't stuck doing CPU-work, it's stuck waiting on some I/O resource. This is especially apparent when you run out of physical memory and start going into the pagefile (although do note that the OS can put memory in the page file at its leisure, even if there's plenty of physical RAM available). Windows is usually pretty smart about this, but it's quite possible to "break" this.

If it really is CPU, it's most likely due to a greedy driver (the vast majority of which is not written by Microsoft). Kernel-mode drivers are exempted from pre-emptive multi-tasking (both for latency and reliability reasons), so if a driver runs a second long loop on the CPU, you're out of luck, it will not be pre-empted.

A great and simple tool to see some of this is Process Explorer (from SysInternals) which shows you the kernel-time of a CPU (ie. how much of the CPU work on the core is done in the kernel, as opposed to the user applications themselves). Windows 7 and later also include this in their task manager (it's the red line in the CPU usage graphs).

В общем, упреждающая многозадачность не избавляет разработчиков ОС от необходимости идти на компромиссы. Это всегда обходится дорого, а планирование задач действительно очень сложно (сейчас моя операционная система манипулирует более чем 2000 потоками - это довольно много, и я ничего не делаю). Было бы лучше уделить потокам меньше времени и тратить больше времени на переключение контекста? Было бы лучше дать им более длинные порции времени, жертвуя латентностью?

Итак, проверьте, что делают жесткие диски. Проверьте, как используется ваша память. Проверьте время ядра. Это вполне вероятно покажет вам, почему Windows теряет отзывчивость, когда вы выполняете тяжелую работу. Некоторые из них можно исправить (освобождая память, ограничивая нарушителя памяти, выбирая привязку к процессору вручную...), некоторые решаются простым обновлением драйверов (графические драйверы были довольно заметны по причинам, которые они вызывали, что, вероятно, сыграло свою роль в Windows, сбрасывая их из режима ядра в режим пользователя в последних версиях).

Кроме того, говоря о графическом процессоре, современные Windows используют ускорение графического процессора для визуализации графического интерфейса (на самом деле, в некоторой степени, так же, как и Windows XP). Если ваше приложение значительно облагает налогом графический процессор, это также может привести к снижению скорости отклика Windows, особенно в Aero. Поскольку графические процессоры все чаще используются в качестве "гипер" процессоров GP, это может быть важно даже вне игр и тому подобного.

Другим серьезным нарушителем является плохо написанное многопоточное приложение. Кэширование памяти довольно легко убить, если вы делаете глупые вещи, а ОЗУ крайне медленное по сравнению с самим ЦП, поэтому без эффективного кеширования ЦП работает очень и очень медленно (даже при том, что он в основном ожидает все время). Это еще сложнее на многоядерных ЦП (и многопроцессорных системах), потому что для обеспечения согласованности многие многопоточные операции требуют аннулирования кэшированных данных (чтобы один ЦП не обращался к "старому" значению переменная в памяти вне ее кеша / регистров). Все это невероятно быстро, но... процессоры быстрее. Намного быстрее. Что, конечно, также представляет проблемы разных поставщиков ЦП, которые по-разному обрабатывают одни и те же вещи, совершенно отдельно от гораздо более высокого уровня ОС. Современные процессоры (486+, так что да, это очень старая особенность, о которой многие программисты даже не подозревают) на самом деле сильно распараллелены, они больше не выполняют одну инструкцию за другой.

Поэтому, даже если ОС делает все идеально (очевидно, невозможный идеал), она все равно может остановиться из-за проблем с оборудованием и связи с оборудованием. Что хорошего в том, что у вас есть 4-ядерный процессор, когда ваше приложение полностью насыщает память R/W? Что хорошего в том, что у него быстрый жесткий диск, когда каждый считываемый байт должен проходить через процессор (помните PIO?). Каждая аппаратная операция, которая не использует прямой доступ к памяти, может потенциально остановить ваш процессор.

И теперь большая часть Windows работает как приложения пользовательского режима. И они взаимодействуют с запущенными приложениями - если я спрошу explorer.exe сделать что-то для меня, он не может сделать что-то еще в то же время. Если я отправлю миллиарду оконных сообщений в окно, оно оставит след.

Просто так много всего происходит, все время... гарантии очень сложны. Обратите внимание, как быстро все становится быстрее, как только появляется экран "ctrl-alt-delete" - внезапно, как будто ничего не случилось:)

Что касается Windows, то Windows 7 работает намного лучше, чем XP, когда дело доходит до такого рода вещей, поэтому я бы не согласился с вашим утверждением "все версии Windows". Но даже с XP, когда вы используете клиентскую версию ОС, Windows отдает приоритет дополнительному приложению (по умолчанию). Независимо от того, какая версия ОС, если все процессы застряли в ожидании одного и того же общего ресурса (это может быть ввод / вывод), все они будут вести себя без ответа.

Еще один способ решения этой проблемы: если explorer.exe занят ожиданием общего ресурса (включая время процессора), то сам рабочий стол / оконный менеджер будет вести себя без ответа. Аналогично для любых приложений, которые прямо или косвенно ожидают освобождения explorer.exe.

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

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

Почему я предлагаю сначала закрыть приложения меньшего размера. Удаляя сначала приложения меньшего размера, вы освобождаете виртуальную память с минимальной активностью диска и быстро отключаете компьютер. Если вы попытаетесь закрыть большое приложение, например, Firefox или Chrome, все они будут расширены. Это связано с тем, что большинство последних приложений имеют фоновые процессы, которые не исчезнут в течение долгого времени, поскольку фоновые процессы также застревают, попадая в файл подкачки и выходя из него. Что еще хуже, они также оказываются с более низким приоритетом, им требуется еще больше времени, чтобы завершить свою деятельность, и весь объем виртуальной памяти, запрашиваемый приложением, должен ждать освобождения, пока не будут выполнены все фоновые процессы и потоки.

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

Другие вопросы по тегам