Комментарии 24
Забавно наблюдать давление legacy, из-за которого всё усложняется количество возможных состояний процессора.
В ARMах это всё как-то логичнее и консистентнее сделано. В том числе и поддержка режимов гипервизоа и защищенной среды, которые реализованны как отдельные режимы работы наравное с режимами обработки прерыванией или data abort.
Один только тот факт, что каждое ядро знает свой core Id и в соответсвии с этим принимает решение о своем участии в процессе загрузки сильно облегчает дело. Никаких гонок и прочего. Просто core 0 грузится, а все остальные — висят в ROM-коде на WFE и ждут команды на старт.
Управление энергопотреблением в случаях c ARM — это вообще не забота процессора. Процессор может только отключить клоки, когда переходит в WFE или WFI (или включать дополнительные, если используется NEON или VFP). А управление частотой и напряжением — забота отдельной логики на SoC. Соответсвенно, никаких аналогов C-states и P-states у процессора просто нет.
И так далее. Мне кажется, что чем проще программная модель процессора, тем лучше программисту.
В ARMах это всё как-то логичнее и консистентнее сделано. В том числе и поддержка режимов гипервизоа и защищенной среды, которые реализованны как отдельные режимы работы наравное с режимами обработки прерыванией или data abort.
Один только тот факт, что каждое ядро знает свой core Id и в соответсвии с этим принимает решение о своем участии в процессе загрузки сильно облегчает дело. Никаких гонок и прочего. Просто core 0 грузится, а все остальные — висят в ROM-коде на WFE и ждут команды на старт.
Управление энергопотреблением в случаях c ARM — это вообще не забота процессора. Процессор может только отключить клоки, когда переходит в WFE или WFI (или включать дополнительные, если используется NEON или VFP). А управление частотой и напряжением — забота отдельной логики на SoC. Соответсвенно, никаких аналогов C-states и P-states у процессора просто нет.
И так далее. Мне кажется, что чем проще программная модель процессора, тем лучше программисту.
И так далее. Мне кажется, что чем проще программная модель процессора, тем лучше программисту.
Это все касается только программистов самой ОС — прикладным программистам это все знать практически бесполезно.
Ну этот пост явно не для прикладных программистов. Прикладные программисты сейчас настолько абстрагированы от железа, что для них архитектура процессора не играет вообще никакой роли. Т.е. раньше если прикладному программисту ещё было важно помнить хотя бы о sizeof(int) или endianess, то сейчас об этом практически не нужно задумываться.
Но всё-таки есть люди которые пишут ОС, гипервизоры, драйвера,вирусы и другие интересные штуки. И вот им желательно иметь в голове модель работы процессора, что бы учитывать всякие крайние случаи, типа VMX-abort shutdown из статьи.
Но всё-таки есть люди которые пишут ОС, гипервизоры, драйвера,
Один только тот факт, что каждое ядро знает свой core Id и в соответсвии с этим принимает решение о своем участии в процессе загрузки сильно облегчает дело. Никаких гонок и прочего. Просто core 0 грузится, а все остальные — висят в ROM-коде на WFE и ждут команды на старт.
Только вот x86 может нести несколько процессоров на борту, и уже всё не так просто становится.
Если дальше поискать то может оказаться что не только из за legacy всё это тянется.
Ну да, может нести несколько процессоров на борту. В SoC'ах на ARM это вообще сплошь и рядом происходит.
В случае x86 всегда есть чипсет, который точно знает сколько у него процессорных сокетов, и во скольких установлены процессоры. Соотвественно чипсет и может раздать всем processor id по порядку.
При чем, я уверен, что нечто подобное уже сделано, потому что BSP же должен как-то перечислить другие процессоры.
В случае x86 всегда есть чипсет, который точно знает сколько у него процессорных сокетов, и во скольких установлены процессоры. Соотвественно чипсет и может раздать всем processor id по порядку.
При чем, я уверен, что нечто подобное уже сделано, потому что BSP же должен как-то перечислить другие процессоры.
Скорей всего это усложнило бы чипсет, и возможно проще это дело решить на софтовом уровне.
Это решается перемычками, вообще-то. Например, EISA-шина или PCI (если не учитывать навороченный программный переключатель). Тот процессор, который в первом слоте — получает сигнал от слота, а последующие — нет, и получают соответсвующие приоритет.ы… Голосование нужно только если «ядра» могут поломаться(не пройти тест на работоспособность), что важно для «удаленно» размещенного железа, но как видится, арбитр, очень сложный, не нужен, тем более только при старте, это шина, возможно, последовательного опроса состояния — стандартный мультиплексор. О каком усложнении идет речь, можно просто подавать напряжение на микросхемы последовательно пока идет инициализация.
Либо отвести старшие биты core id под номер сокета, а младшие под номер ядра.
Я помню магическую комбинацию команд CLI / HLT, которая в свое время наглухо весила комп с любой ОС. На Pentium-е уже такая фишка не работала.
НЛО прилетело и опубликовало эту надпись здесь
Я могу ошибаться, но по-моему срабатывало как раз в виртуальном режиме: делаешь .com-файл из двух байт, и пускаешь его. И Win95 и OS/2 наглухо висли. Причем, вроде бы срабатывало только на процессорах AMD 486. На четверках Intel-а ничего не происходило.
mov al,1
out 92h,alИз-под V86 спокойно перезагружает комп на 98-й винде (пробовал у себя через VMware – перезагружал, естественно, гостевую) :)
cli/hlt в r0 из-под PMode тоже вполне спокойно вешает систему (конечно, от NMI/SMI не защитит, но они почти наверняка и не возникнут).
cli
jmp $Вполне успешно вешает комп в той же 98-й, будучи запущенной из-под V86 (а вот cli/hlt вылетает с исключением).
Кроме того, монитор может запускать гостя в режиме non-root в состоянии shutdown (уж не знаю, зачем это может понадобиться).
О, это очень нужная штука. Допустим, надо нам восстановить состояние VM на какой-то момент времени — запускаем VM с выключенным процессором, загружаем в RAM содержимое памяти VM из файла на диске, запускаем процессор. Или live migration — запускаем VM с выключенным CPU, копируем содержимое RAM из другой VM, запускаем процессор.
Спасибо за статью, уважаемый Atakua. Сколько не работай с x86 на уровне «ниже уже железо», все равно узнаешь массу нового.
Если можно, напишите в следующий раз про состояния энергосбережения: C-State, P-State, NB/Mem P-State, T-State, EIST, CPPС, DPTF, вот это все. Понятно, что все есть в даташитах, но статья на русском будет полезна в любом случае.
Если можно, напишите в следующий раз про состояния энергосбережения: C-State, P-State, NB/Mem P-State, T-State, EIST, CPPС, DPTF, вот это все. Понятно, что все есть в даташитах, но статья на русском будет полезна в любом случае.
Про режимы энергосбережения попробую написать. Хотя я напрямую не работаю с ними, у меня под рукой есть довольно много публикаций на английском по этой теме (например, вот эта книга "Energy Efficient Servers. Blueprints for Data Center Optimization", бесплатная в PDF варианте). На русском, пожалуй, знаю только об одном бакалаврском дипломе (подготовленном в нашем отделе).
Тема, конечно, необъятная, учитывая, что в секторах серверов, десктопов и встраиваемых систем на основе IA-32 детали реализации могут очень сильно отличаться.
Я тоже с ними почти не работаю, потому что в Embedded и Industrial все эти вещи стараются отключить, т.к. они плохо влияют на предсказуемость системы. Сколько Intel и AMD не стараются убрать это влияние, оно все равно есть и очень заметно для людей, пытающихся выжать из x86-64 хотя бы SoftRT.
Тем не менее, «врага нужно знать в лицо», поэтому буду рад, если у вас все же получится написать что-нибудь по теме.
Тем не менее, «врага нужно знать в лицо», поэтому буду рад, если у вас все же получится написать что-нибудь по теме.
Всегда узнаёшь что-то в первый раз)
Извиняюсь за вопрос дилетанта, но…
Давно уже подметил, что на OSX и Linux-based платформах компьютер по-настоящему засыпает, а вот с Win не всё так просто. Может быть стоит просветить массы?
Давно уже подметил, что на OSX и Linux-based платформах компьютер по-настоящему засыпает, а вот с Win не всё так просто. Может быть стоит просветить массы?
Что значит «по настоящему засыпает»?
Ох, постараюсь объяснить…
Например, на сколько я могу судить, OSX полностью отрубается HDD, которому потом требуется время на «раскрутку» (т.е. системе требуется время, чтобы проснуться), «засыпают» интерфейсы аля wifi и BT.
Плюс режим бездействия. Частенько на OSX без нагрузки кулер процессора не работает — тишина и покой, а вот на Win всегда крутится.
Например, на сколько я могу судить, OSX полностью отрубается HDD, которому потом требуется время на «раскрутку» (т.е. системе требуется время, чтобы проснуться), «засыпают» интерфейсы аля wifi и BT.
Плюс режим бездействия. Частенько на OSX без нагрузки кулер процессора не работает — тишина и покой, а вот на Win всегда крутится.
Если очень кратко, то:
- Стандарт ACPI определяет интерфейсы управления энергопотреблением платформы (ЦПУ, материнская плата и периферийные устройства) для ОС.
- Стандарт определяет состояния энергопотребления и производительности: для системы в целом (S0-S5), процессора (C- и P-состояния; эта статья лишь слегка коснулась C-состояний), периферийных устройств (D-состояния).
- Стандарт не диктует обязательность реализации всех объявленных в нём режимов. Детали реализации режимов различаются для разной аппаратуры. Кроме того, операционные системы вольны реализовывать только некоторые из режимов сна.
- За засыпание отдельных устройств отвечают их драйвера. Но что-то подсказывает мне, что обеспечение корректной поддержки D-состояний не стоит в первом приоритете у драйверописателей. Поэтому то, насколько глубоко заснёт конкретный девайс, может отличаться на разных ОС или ревизиях одной ОС.
Ноутбук Dell — прошивка биоса А14 — кулер молчит и не крутится, когда нет сильной нагрузки. Пришло обновление биоса А15 — кулер крутиться всегда, при питании от сети 220В, даже без нагрузки и при минимальной температуре, ну только что медленно и чуть слышно его. Винда, естественно — не менялась при этом.
Связано было с тем, что внутри ноута стоит стремный чип Нвидиа, который любил перегреваться и выходить из строя.
Связано было с тем, что внутри ноута стоит стремный чип Нвидиа, который любил перегреваться и выходить из строя.
В Linux'е по логам хорошо видно, как засыпают устройства в момент перехода системы в S3:
Здесь видно, что выключается видеокарта и жесткий диск. Когда система просыпается, то видно, что спали еще и Fireware, Ethernet и Wi-Fi
[ 2157.872393] firewire_core 0000:01:06.0: rediscovered device fw0
[ 2158.540078] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2158.552634] ata3.00: configured for UDMA/133
[ 2159.014382] forcedeth 0000:00:0a.0: irq 42 for MSI/MSI-X
[ 2159.014441] forcedeth 0000:00:0a.0 eth0: MSI enabled
[ 2159.014676] forcedeth 0000:00:0a.0 eth0: no link during initialization
[ 2159.015157] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2159.046213] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 2161.608208] wlan0: authenticate with <MA:CA:DD:RE:SS>
У видны в логах пусто — только «Система переходит в спящий режим» и «Система вышла из спящего режима». Так что стоит под виндами обновить драйверы и посмотреть настройки BIOS на предмет спящего режима. Надо сказать, что я ни разу не сталкивался с тем, что винда «засыпала» ноутбук недостаточно глубоко, а вот неспособноть Linux'а перевести ноут в спящий режим попадалась.
[ 2146.658947] PM: Syncing filesystems ... done.
[ 2147.619043] PM: Preparing system for mem sleep
[ 2147.883129] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 2147.886118] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 2147.887436] PM: Entering mem sleep
[ 2147.887559] Suspending console(s) (use no_console_suspend to debug)
[ 2147.889020] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 2147.889403] sd 2:0:0:0: [sda] Stopping disk
[ 2147.937245] nouveau [ DRM] suspending console...
[ 2147.937275] nouveau [ DRM] suspending display...
[ 2147.937339] nouveau [ DRM] evicting buffers...
[ 2156.748841] nouveau [ DRM] waiting for kernel channels to go idle...
[ 2156.748848] nouveau [ DRM] suspending client object trees...
[ 2156.749241] nouveau [ DRM] suspending kernel object tree...
[ 2157.060145] PM: suspend of devices complete after 9171.825 msecs
[ 2157.061307] PM: late suspend of devices complete after 1.153 msecs
[ 2157.063029] ehci-pci 0000:00:04.1: System wakeup enabled by ACPI
[ 2157.063062] ehci-pci 0000:00:02.1: System wakeup enabled by ACPI
[ 2157.063085] ohci-pci 0000:00:04.0: System wakeup enabled by ACPI
[ 2157.063104] ohci-pci 0000:00:02.0: System wakeup enabled by ACPI
[ 2157.076277] PM: noirq suspend of devices complete after 14.959 msecs
[ 2157.076383] ACPI: Preparing to enter system sleep state S3
[ 2157.087166] PM: Saving platform NVS memory
[ 2157.088514] Disabling non-boot CPUs ...
[ 2157.090199] kvm: disabling virtualization on CPU1
[ 2157.192042] smpboot: CPU 1 is now offline
Здесь видно, что выключается видеокарта и жесткий диск. Когда система просыпается, то видно, что спали еще и Fireware, Ethernet и Wi-Fi
[ 2157.872393] firewire_core 0000:01:06.0: rediscovered device fw0
[ 2158.540078] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2158.552634] ata3.00: configured for UDMA/133
[ 2159.014382] forcedeth 0000:00:0a.0: irq 42 for MSI/MSI-X
[ 2159.014441] forcedeth 0000:00:0a.0 eth0: MSI enabled
[ 2159.014676] forcedeth 0000:00:0a.0 eth0: no link during initialization
[ 2159.015157] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2159.046213] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 2161.608208] wlan0: authenticate with <MA:CA:DD:RE:SS>
У видны в логах пусто — только «Система переходит в спящий режим» и «Система вышла из спящего режима». Так что стоит под виндами обновить драйверы и посмотреть настройки BIOS на предмет спящего режима. Надо сказать, что я ни разу не сталкивался с тем, что винда «засыпала» ноутбук недостаточно глубоко, а вот неспособноть Linux'а перевести ноут в спящий режим попадалась.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делает центральный процессор, когда ему нечего делать