что делает процессор, когда ничего не делает

примерно то же, что и машина на холостых - просто крутит двигатель, а вся остальная часть в состоянии покоя.

ну приминительно к процессору, это либо холостой цикл типа for (;;); или все-таки он выплняет эту команду hlt

Щас глянул что там в Minix 1.7.5:

!*===========================================================================*
!*				idle_task				     *
!*===========================================================================*
_idle_task:			! executed when there is no work
	jmp	_idle_task	! a "hlt" before this fails in protected mode

UPD: MINIX3:

/*===========================================================================*
 *				idle					     * 
 *===========================================================================*/
static void idle(void)
{
	struct proc * p;

	/* This function is called whenever there is no work to do.
	 * Halt the CPU, and measure how many timestamp counter ticks are
	 * spent not doing anything. This allows test setups to measure
	 * the CPU utilization of certain workloads with high precision.
	 */

	p = get_cpulocal_var(proc_ptr) = get_cpulocal_var_ptr(idle_proc);
	if (priv(p)->s_flags & BILLABLE)
		get_cpulocal_var(bill_ptr) = p;

	switch_address_space_idle();

#ifdef CONFIG_SMP
	get_cpulocal_var(cpu_is_idle) = 1;
	/* we don't need to keep time on APs as it is handled on the BSP */
	if (cpuid != bsp_cpu_id)
		stop_local_timer();
	else
#endif
	{
		/*
		 * If the timer has expired while in kernel we must
		 * rearm it before we go to sleep
		 */
		restart_local_timer();
	}

	/* start accounting for the idle time */
	context_stop(proc_addr(KERNEL));
#if !SPROFILE
	halt_cpu();
#else
	if (!sprofiling)
		halt_cpu();
	else {
		volatile int * v;

		v = get_cpulocal_var_ptr(idle_interrupted);
		interrupts_enable();
		while (!*v)
			arch_pause();
		interrupts_disable();
		*v = 0;
	}
#endif
	/*
	 * end of accounting for the idle task does not happen here, the kernel
	 * is handling stuff for quite a while before it gets back here!
	 */
}

Процессор делает гораздо больше, чтобы не работать: https://www.thomas-krenn.com/en/wiki/Processor_P-states_and_C-states

Ничего не делать можно по разному.

Процессор может отключиться полностью, может войти в спящий режим (которых несколько типов), может отключить питание на всех ядрах кроме одного, а это одно перевести в режим с пониженной частотой.

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

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

В зависимости от процессора, до полного обесточения ядра. Старые - хреначили бесконечный цикл (выполняли команду hlt).

Стек команд не может быть пустой, т.к. его нет :) Есть IP, и, если не рассматривать тонкости предсказателя, то ядро просто со своей текущей тактовой частотой исполняет команду по адресу IP, либо команда меняет IP либо IP инкрементируется, чтобы оно этого не делало его нужно обесточить или ещё как-то остановить(например до наступления определённого прерывания), чтобы оно делало это реже - нужно понизить его тактовую тактовую частоту.

Чисто логически он должен быть в цикле, чтобы принять следующую команду иначе он «умрёт»...

когда ничего не делает

idle делает

Чисто логически он должен быть в цикле, чтобы принять следующую команду иначе он «умрёт»...

Не-а. После hlt процессор просыпается по аппаратному прерыванию. Во времена Win95 все знали как создать двухбайтный com-файл из команд cli и hlt, вешающих венду насмерть. :)

Делает вид что что-то делает.

Во времена Win95 все знали как создать двухбайтный com-файл из команд cli и hlt, вешающих венду насмерть. :)

О-па! Спасибо, вот это было интересно, в т.ч. по сабжевой теме.

halt это как бы правильнее ибо это и есть останов процессора

Windows 9x можно завесить резко и намертво прямо из командной строки (run...), безо всяких файлов и их создания.

Ну о чем и речь, ответ зависит от того на каком уровне абстракции мы находимся.

из команд cli и hlt

Там же был jmp на себя, а не hlt. И пишут, это было сделано специально, чтобы старые программы под MS-DOS продолжали работать с железом. Там целый цирк с конями для того, чтобы резидентные программы, запущенные в DOS’е продолжали работать в Windows 95, работающей в защищённом режиме.

Реймонд Чэн писал, что и поддержку hlt в Windows 95 добавляли на этапе разработки, но из-за бага на каких-то там компьютерах вызов hlt блокировал систему наметрво, из-за чего фичу из кода убрали.

С точки зрения електроники процессор не может «ничего» не делать. Как только на нем есть достаточное для стабильной работы напряжение и есть тактирование (грубо говоря кристал осцилятор подключен) он бежит по памяти и исполняет инструкции. Для того что бы «усыпить» проц, с него надо снять тактирование. Но ет простое обьяснение «физики» работы проца. Современные процы имеют огромное количество кода которое борется за еффективность «бегания по памяти и исполнения», а так же за консистентность перехода в сон и выхода из него...

имеется в виду, на x86 и ос Linux, Windows и т.д.

А бывает такое в современных ОС чтоб процессор вообще ничего не делал? Тут же куча фоновых процессов, всякая там периферия.

Считает такты счётчиком тактов.

когда uptime 0.00, то видимо ничего и не делает, только прерывания обрабатывает, смотрит, что ниодного процесса не запланировано и опять уходит в спячку или холостой цикл (я так и не понял из этого топика, куда он уходит, но понял, что все сложно)

Я тоже мало что понял..

если команда hlt заставляет процессор перестать выполнять команды из ip, то, вероятно, он ее и выполняет до возникновения прерывания, которое перекидывает ip на другую часть кода, которую он и начинает выполнять, то тогда видимо он выполняет hlt, пока не возникнет прерывание (это видимо упрощенно) если же команда халт не переводит его в спящее состояние, то фиг знает, что он делает, когда делать нечего

Там же был jmp на себя, а не hlt.

Где - «там»? Я и мои друзья лично писали такие программы и запускали их на разных компах с вендами, чтобы проверить горячую новость из fido ещё кажется.

но из-за бага на каких-то там компьютерах вызов hlt блокировал систему наметрво, из-за чего фичу из кода убрали.

Просто hlt в Win95 ничего не блокировал, процессор просыпался по аппаратному прерываних, хотя бы от таймера. Вешало на смерть именно комбинация cli hlt, как и в DOS. В NT4 как и положено висла только одна dos-сессия.

но из-за бага на каких-то там компьютерах

Нашёл эту статью. Вообще, смешение тёплого с мягким. Придётся дополнять Чэна (расту! :-D) и пояснять то, что уже не понятно.

hlt входит в оригинальный набор инструкций 8086/8088. hlt используется в цикле ожидания многозадачных систем (впервую очередь), чтобы притормозить процессор пока не произойдёт аппаратное прерывание.

В DOS hlt не использовалась, потому что DOS однозадачная и вызывать hlt там просто не где.

В Windows 3.x многозадачность кооперативная, вызывать hlt можно, но разве что в ядре в момент, когда активных задач нет, но учитывая, что Windows 3.x была не полностью автономной и могла плотно взаимодействовать с кодом DOS (например, драйверами жёстких дисков) реализовать её вызов не имело особого смысла.

Windows NT 3.x, 4.0, а так же Windows 9x были уже системами с вытесняющей многозадачностью, гораздо более автономными, хотя Windows 9x всё ещё могла задействовать драйверы из DOS и Windows 3.x. Там реализовать вызов hlt в цикле ожидания ядра смысл был. Но сделано это не было. В информативном диспетчере задач Windows NT 4 можно было видеть, что процессор постоянно загружен.

Как пишет Чэн: «После выхода Windows 95 как грибы после дождя начали плодиться программы, вызывающие HLT.» (На самом деле в этих программах не было особого толка, т.к. почти никто из них не патчил ядро, а вызов hlt в произвольном месте эффекта не даёт. Так-то умельцы и для DOS пытались резиденты вызывающие hlt писать.)

Для Windows NT 4 был «фанатский» патч ядра, который наконец встраивал вызов hlt в цикл ожидания. Я его в обязательном порядке ставил. :) За давностью лет не помню, появилась ли официальное ядро со встроенным hlt или нет, с очередным сервис-паком, я не помню.

Теперь, благодаря Чэну мы знаем почему hlt не было в ядрах ранних 32-битных Windows. Дело не в баге Windows и не во всех компьютерах. Некоторые компьютеры, включая некие ноутбуки «от весьма известного производителя», которые висли от простого вызова hlt.

Здесь же, с cli hlt, гарантированно висли любые Windows 9x на любом железе. cli jmp на себя вероятно должно давать тот же эффект. jmp на себя реализует вечный цикл, а предшествующая ему cli эффективно блокирует прерывания, не давая шанса завершить программу.

Сам факт того, что из третьего кольца можно было вызвать реальный cli, не говоря уже о hlt, говорит о том, что в Windows 9x защита системы была похожа на дырявый штакетник.

Впрочем, тут топик о hlt, а не о лучшем способе завесить венду...

Где - «там»?

В тех источниках, из которых до меня дошёл рецепт завешивания, был jmp. Да и потом везде, где в интернете встречал, упоминался jmp. Про вариант с hlt в первый раз здесь прочитал.

На самом деле в этих программах не было особого толка, т.к. почти никто из них не патчил ядро

А вот тут бенчмарки показывают, что эффект был: http://www.benchtest.com/cooltest.html

Некоторые компьютеры

Это в смысле «ах, какие они глупые, это всего-то на некоторых компьютерах», что ли?

Сам факт того, что из третьего кольца можно было вызвать реальный cli, не говоря уже о hlt, говорит о том, что в Windows 9x защита системы была похожа на дырявый штакетник.

Не проверял, но сильно сомневаюсь, что вызов cli в Windows-приложении даст тот же эффект. Всё-таки самый важный момент во всей этой истории состоит в том, что cli нужно вызывать в сессии MS-DOS. У Чена в другой статье (https://devblogs.microsoft.com/oldnewthing/20151204-00/?p=92281) упоминалось, что решение разрешить cli было осмысленным. Нужно было поддерживать MS-DOS программы для существующего оборудования, а ведь эти программы могут быть очень чувствительны к непресказуемым задержкам от вытеснения задач.

Это в смысле «ах, какие они глупые, это всего-то на некоторых компьютерах», что ли?

Повторяю медлено: Это в смысле вы писали о статье, где говорится о частном случае, а я об общем. Вот после этих слов «но из-за бага на каких-то там компьютерах» я нашёл статью о глючных ноутах, а не конкретно о cli jmp.

Ну что ж, значит во всём мире был более распространён вариант с jmp. Хотя технически вариант с hlt «круче». С jmp процессор продолжает молотить вечный цикл, когда с hlt просто отключается.

упоминалось, что решение разрешить cli было осмысленным

Ясен пень осмысленным. Эта инструкция (в отличии от hlt) использовалась в DOS программах. Windows 9x пыталась эмулировать DOS-сессию куда сильнее NT, в которой таким образом завесить было невозможно. Но и цена у такой поддержки была ощутимой. Венда, падающая от каждого чиха.

Повторяю медлено

Предлагаю перечитать медленно. У меня текст разделён на два абзаца, в которых говорится о разных аспектах отношения Windows к hlt. Поэтому это два отдельных абзаца. Отдельных. Два.

Windows 9x пыталась эмулировать DOS-сессию куда сильнее NT <…>. Но и цена у такой поддержки была ощутимой. Венда, падающая от каждого чиха.

Нет логической связи между этими высказываниями.

Да и потом везде, где в интернете встречал, упоминался jmp.

Случайно наткнулся на старый пост человека на хабре: https://habr.com/ru/post/179543/#comment_6233293

Так что точно не один я про hlt вместо jmp знал.