Ядро windows 10 где находится
Обновлено: 06.07.2024
Ядро состоит из набора функций, находящихся в файле Ntoskrnl.exe. Этот набор предоставляет основные механизмы (службы диспетчеризации потоков и синхронизации), используемые компонентами исполняющей системы, а также поддержкой архитектурно-зависимого оборудования низкого уровня (например, диспетчеризацией прерываний и исключений), которое имеет отличия в архитектуре каждого процессора.
Код ядра написан главным образом на C, с ассемблерным кодом, предназначенным для задач, требующих доступа к специальным инструкциям и регистрам процессора, доступ к которым из кода на языке C затруднен.
Подобно различным вспомогательным функциям, ряд функций ядра документированы в WDK (и их описание может быть найдено при поиске функций, начинающихся с префикса Ke), поскольку они нужны для реализации драйверов устройств.
Объекты ядра.
Ядро предоставляет низкоуровневую базу из четко определенных, предсказуемых примитивов и механизмов операционной системы, позволяющую высокоуровневым компонентам исполняющей системы выполнять свои функции. Само ядро отделено от остальной исполняющей системы путем реализации механизмов операционной системы и уклонения от выработки политики. Оно оставляет почти все политические решения, за исключением планирования и диспетчеризации потоков, реализуемых ядром, за исполняющей системой.
За пределами ядра исполняющая система представляет потоки и другие ресурсы совместного использования в виде объектов. Эти объекты требуют некоторых издержек, например, на дескрипторы для управления ими, на проверки безопасности для их защиты и на ресурсные квоты, выделяемые при их создании.
В ядре, реализующем набор менее сложных объектов, называемых «объектами ядра», подобные издержки исключены, что помогает ядру управлять основной обработкой и поддерживать создание исполняющих объектов. Большинство объектов уровня исполнения инкапсулируют один или несколько объектов ядра, принимая их, определенные в ядре свойства.
Один набор объектов ядра, называемых «управляющими объектами», определяет семантику управления различными функциями операционной системы.
В этот набор включены объекты асинхронного вызова процедур — APC, отложенного вызова процедур — deferred procedure call (DPC), и несколько объектов, используемых диспетчером ввода-вывода, например, объект прерывания.
Еще один набор объектов ядра, известных как «объекты-диспетчеры», включает возможности синхронизации, изменяющие или влияющие на планирование потоков. Объекты-диспетчеры включают поток ядра, мьютекс (называемый среди специалистов «мутантом»), событие, пару событий ядра, семафор, таймер и таймер ожидания. Исполняющая система использует функции ядра для создания экземпляров объектов ядра, работы с ними и создания более сложных объектов, предоставляемых в пользовательском режиме.
Область ядра, относящаяся к управлению процессором, и блок управления (KPCR и KPRCB).
Для хранения специфических для процессора данных ядром используется структура данных, называемая областью, относящейся к управлению процессором, или KPCR (KernelProcessorControlRegion). KPCR содержит основную информацию, такую как процессорная таблица диспетчеризации прерываний (interrupt dispatch table, IDT), сегмент состояния задачи (task-state segment, TSS) и таблица глобальных дескрипторов (globaldescriptortable, GDT). Она также включает состояние контроллера прерываний, которое используется вместе с другими модулями, такими как ACPI-драйвер и HAL.
Для обеспечения простого доступа к KPCR ядро хранит указатель на эту область в регистре fs на 32-разрядной системе Windows и в регистре gs на Windows-системе x64. На системах IA64 KPCR всегда находится по адресу 0xe0000000ffff0000.
KPCR также содержит вложенную структуру данных, которая называется блоком управления процессором (kernelprocessorcontrolblock, KPRCB). В отличие от области KPCR, которая документирована для драйверов сторонних производителей и для других внутренних компонентов ядра Windows, KPRCB является закрытой структурой, используемой только кодом ядра, который находится в файле Ntoskrnl.exe.
В этом блоке содержится:
- информация о планировании (такая как текущий, следующий и приостановленный потоки, предназначенные для выполнения на процессоре);
- предназначенная для процессора база данных диспетчера (включающая готовые очереди для каждого приоритетного уровня);
- DPC-очередь;
- информация о производителе центрального процессора и идентификационная информация (модель, степпинг, скорость, биты особенностей);
- информация о топологии центрального процессора и о технологии доступа к неоднородной памяти — NUMA (информация об узле, о количестве логических процессоров в каждом ядре и т. д.);
- информация о размерах кэш-памяти;
- информация об учете времени (такая как время DPC и обработки прерывания) и многое другое.
В KPRCB также содержится вся статистика процессора, такая как статистика ввода-вывода, статистика диспетчера кэша, статистика DPC и статистика диспетчера памяти. И наконец, KPRCB иногда используется для хранения структур выравнивания границ кэша для каждого процессора, необходимых для оптимизации доступа к памяти, особенно на NUMA-системах. Например, система невыгружаемого и выгружаемого пула со стороны выглядит как списки, хранящиеся в KPRCB.
Эксперимент: просмотр KPCR и KPRCB.
Содержимое KPCR и KPRCB можно просмотреть, используя команды отладки ядра !pcr и !prcb. Без пометок отладчик по умолчанию покажет информацию для центрального процессора 0; но вы можете указать центральный процессор, добавив после команды его номер (например, !pcr 2).
В следующем примере показано, как выглядит вывод команд !pcr и !prcb.
Если в системе имелись задержанные DPC-вызовы, эта информация также будет отображена на экране.
Для непосредственного вывода дампа структур данных _KPCR и _KPRCB можно воспользоваться командой dt, поскольку обе команды отладки дают вам адреса структур (которые для наглядности выделены в предыдущем выводе жирным шрифтом). Например, если нужно определить скорость процессора, можно с помощью следующей команды посмотреть на поле MHz:
lkd> dt nt!_KPRCB 81d09920 MHz
+0x3c4 MHz : 0xbb4
lkd> ? bb4
Evaluate expression: 2996 = 00000bb4
Windows – одна из наиболее многогранных и гибких ОС, она работает на совершенно разных архитектурах и доступна в разных вариантах. На сегодня она поддерживает архитектуры x86, x64, ARM и ARM64. Windows в своё время поддерживала Itanium, PowerPC, DEC Alpha и MIPS. Кроме того, Windows поддерживает целый набор SKU, работающих в различных условиях; от дата-центров, ноутбуков, Xbox и телефонов до встраиваемых версий для интернета вещей, например, в банкоматах.
Самый удивительный аспект состоит в том, что ядро Windows практически не меняется в зависимости от всех этих архитектур и SKU. Ядро динамически масштабируется в зависимости от архитектуры и процессора, на котором оно работает, так, чтобы пользоваться всеми возможностями оборудования. Конечно, в ядре присутствует определённое количество кода, связанного с конкретной архитектурой, однако его там минимальное количество, что позволяет Windows запускаться на разнообразных архитектурах.
В этой статье я расскажу об эволюции ключевых частей ядра Windows, которые позволяют ему прозрачно масштабироваться от чипа NVidia Tegra низкого потребления, работающего на Surface RT 2012 года, до гигантских монстров, работающих в дата-центрах Azure.
Менеджер задач Windows, работающий на пререлизной машине класса Windows DataCenter, с 896 ядрами, поддерживающими 1792 логических процессора и 2 Тб памяти
Эволюция единого ядра
Перед тем, как обсудить детали ядра Windows, сделаем небольшое отступление в сторону рефакторинга. Рефакторинг играет ключевую роль в увеличении случаев повторного использования компонентов ОС на различных SKU и платформах (к примеру, клиент, сервер и телефон). Базовая идея рефакторинга – позволить повторно использовать одни и тем же DLL на разных SKU, поддерживая небольшие модификации, сделанные специально под нужный SKU, не переименовывая DLL и не ломая работу приложений.
Базовая технология рефакторинга Windows – мало документированная технология под названием "наборы API". Наборы API – это механизм, позволяющий ОС разъединять DLL и место их применения. К примеру, набор API позволяет приложениям для win32 продолжать пользоваться kernel32.dll, притом, что реализация всех API прописана в другой DLL. Эти DLL с реализацией также могут отличаться у разных SKU. Посмотреть наборы API в деле можно, запустив обход зависимостей на традиционной Windows DLL, например, kernel32.dll.
Закончив это отступление по поводу строения Windows, позволяющего системе максимизировать повторное и совместное использование кода, перейдём к техническим глубинам запуска ядра по планировщику, являющегося ключом к масштабированию ОС.
Компоненты ядра
Windows NT – это, по сути, микроядро, в том смысле, что у него есть своё core Kernel (KE) с ограниченным набором функций, использующее исполняемый уровень (Executive layer, Ex) для выполнения всех политик высокого уровня. EX всё ещё является режимом ядра, так что это не совсем микроядро. Ядро отвечает за диспетчеризацию потоков, синхронизацию между процессорами, обработку исключений аппаратного уровня и реализацию низкоуровневых функций, зависящих от железа. Слой EX содержит различные подсистемы, обеспечивающие набор функциональности, который обычно считается ядром – IO, Object Manager, Memory Manager, Process Subsystem, и т.д.
Чтобы лучше представить себе размер компонентов, вот примерное разбиение по количеству строк кода в нескольких ключевых каталогах дерева исходников ядра (включая комментарии). В таблицу не вошло ещё много всего, относящегося к ядру.
| Подсистемы ядра | Строк кода |
|---|---|
| Memory Manager | 501, 000 |
| Registry | 211,000 |
| Power | 238,000 |
| Executive | 157,000 |
| Security | 135,000 |
| Kernel | 339,000 |
| Process sub-system | 116,000 |
Более подробная информация об архитектуре Windows содержится в серии книг “Windows Internals”.
Планировщик
Подготовив таким образом почву, давайте немного поговорим о планировщике, его эволюции и том, как ядро Windows умеет масштабироваться на такое количество различных архитектур с таким большим количеством процессоров.
Поток – это базовая единица, исполняющая программный код, и именно её работу планирует планировщик Windows. Решая, какой из потоков запустить, планировщик использует их приоритеты, и в теории, поток с наивысшим приоритетом должен запускаться на системе, даже если это означает, что потокам с более низким приоритетам времени не останется.
У планировщика Windows изначально была одна очередь готовности, из которой он выбирал следующий, наивысший по приоритету поток для запуска. Однако с началом поддержки всё большего количества процессоров, единственная очередь превратилась в узкое место, и примерно в районе выхода Windows Server 2003 планировщик поменял работу и организовал по одной очереди готовности на процессор. При переходе на поддержку нескольких запросов на один процессор единую глобальную блокировку, защищающую все очереди, делать не стали, и разрешили планировщику принимать решения на основе локальных оптимумов. Это означает, что в любой момент в системе работает один поток с наивысшим приоритетом, но не обязательно означает, что N самых приоритетных потоков в списке (где N – число процессоров) работают в системе. Такой подход оправдывал себя, пока Windows не начала переходить на CPU с низким энергопотреблением, например, на ноутбуки и планшеты. Когда на таких системах поток с наивысшим приоритетам не работал (например, поток переднего плана интерфейса пользователя), это приводило к заметным глюкам интерфейса. Поэтому в Windows 8.1 планировщик перевели на гибридную модель, с очередями для каждого процессора для потоков, связанных с этим процессором, и разделяемой очередью готовых процессов для всех процессоров. Это не сказалось на быстродействии заметным образом благодаря другим изменениям в архитектуре планировщика, например, рефакторингу блокировки базы данных диспетчера.
В Windows 7 ввели такую вещь, как динамический планировщик со справедливыми долями (Dynamic Fair Share Scheduler, DFSS); это в первую очередь касалось терминальных серверов. Эта особенность пыталась решить проблему, связанную с тем, что одна терминальная сессия с высокой загрузкой CPU могла повлиять на потоки в других терминальных сессиях. Поскольку планировщик не учитывал сессии и просто использовал приоритет для распределения потоков, пользователи в разных сессиях могли повлиять на работу пользователей в других сессиях, задушивая их потоки. Также это давало несправедливое преимущество сессиям (и пользователям) с большим количеством потоков, поскольку у сессии с большим количеством потоков было больше возможностей получить процессорное время. Была сделана попытка добавить в планировщик правило, по которому каждую сессию рассматривали на равных с другими по количеству процессорного времени. Подобная функциональность есть и в ОС Linux с их абсолютно честным планировщиком (Completely Fair Scheduler). В Windows 8 эту концепцию обобщили в виде группы планировщика и добавили в планировщик, в результате чего каждая сессия попадала в независимую группу. Кроме приоритетов для потоков, планировщик использует группы планировщика как индекс второго уровня, принимая решение по поводу того, какой поток запускать следующим. В терминальном сервере все группы планировщика имеют одинаковый вес, поэтому все сессии получают одинаковое количество процессорного времени вне зависимости от количества или приоритетов потоков внутри групп планировщика. Кроме того, такие группы также используют для более точного контроля над процессами. В Windows 8 рабочие объекты (Job) были дополнены так, чтобы поддерживать управление процессорным временем. При помощи специального API можно решать, какую часть процессорного времени может использовать процесс, должно это быть мягкое или жёсткое ограничение, и получать уведомления, когда процесс достигает этих ограничений. Это похоже на управление ресурсами в cgroups на Linux.
Начиная с Windows 7, в Windows Server появилась поддержка более 64 логических процессоров на одном компьютере. Чтобы добавить поддержку такому большому количеству процессоров, в системе ввели новую категорию, «процессорная группа». Группа – неизменный набор логических процессоров количеством не более 64 штук, которые рассматриваются планировщиком как вычислительная единица. Ядро при загрузке определяет, какой процессор к какой группе отнести, и у машин с количеством процессорных ядер менее 64 этот подход практически невозможно заметить. Один процесс может разделяться на несколько групп (например, экземпляр SQL-сервера), единственный поток в один момент времени может выполняться только в рамках одной группы.
Но на машинах, где число ядер CPU превышает 64, Windows начала демонстрировать новые узкие места, не дававшие таким требовательным приложениям, как SQL-сервер, масштабироваться линейно с ростом количества ядер процессора. Поэтому, даже при добавлении новых ядер и памяти, замеры скорости не показывали её существенного увеличения. Одной из главных проблем, связанных с этим, был спор по поводу блокировки базы диспетчера. Блокировка базы диспетчера защищала доступ к объектам, работу которых необходимо было запланировать. Среди этих объектов – потоки, таймеры, порты ввода/вывода, другие объекты ядра, подверженные ожиданию (события, семафоры, мьютексы). Под давлением необходимости разрешения таких проблем, в Windows 7 была проделана работа по устранению блокировки базы диспетчера и замене её на более точные подстройки, например, пообъектную блокировку. Это позволило таким замерам производительности, как SQL TPC-C, продемонстрировать рост скорости на 290% по сравнению с предыдущей схемой на некоторых конфигурациях. Это был один из крупнейших взлётов производительности в истории Windows, случившихся благодаря изменению единственной особенности.
Windows 10 принесло другую инновацию, внедрив наборы процессоров (CPU Sets). CPU Sets позволяют процессу разделять систему так, что процесс может распределиться на несколько групп процессоров, не позволяя другим процессам пользоваться ими. Ядро Windows даже не даёт прерываниям устройств пользоваться процессорами, входящими в ваш набор. Это гарантирует, что даже устройства не смогут исполнять свой код на процессорах, выданных группе вашего приложения. Это похоже на низкотехнологичную виртуальную машину. Понятно, что это мощная возможность, поэтому в неё встроено множество мер безопасности, чтобы разработчик приложения не допустил больших ошибок, работая с API. Функциональность наборов CPU используется в игровом режиме (Game Mode).
Наконец, мы приходим к поддержке ARM64, появившейся у Windows 10. Архитектура ARM поддерживает архитектуру big.LITTLE, гетерогенную по своей природе – «большое» ядро работает быстро и потребляет много энергии, а «малое» ядро работает медленно и потребляет меньше. Идея в том, что малозначительные задачи можно выполнять на малом ядре, экономя таким образом батарею. Для поддержки архитектуры big.LITTLE и увеличения времени работы от батареи при работе Windows 10 на ARM, в планировщик добавили поддержку гетерогенной планировки, учитывающую пожелания приложения, работающего с архитектурой big.LITTLE.
Под пожеланиями я имею в виду то, что Windows старается качественно обслуживать приложения, отслеживая потоки, выполняющиеся на переднем плане (или те, которым не хватает процессорного времени), и гарантируя их выполнение на «большом» ядре. Все фоновые задачи, сервисы, другие вспомогательные потоки выполняются на малых ядрах. Также в программе можно принудительно отметить маловажность потока, чтобы заставить его работать на малом ядре.
Работа от чужого имени [Work on Behalf]: в Windows довольно много работы на переднем плане осуществляется другими сервисами, работающими в фоне. К примеру, при поиске в Outlook сам поиск проводится фоновым сервисом Indexer. Если мы просто запустим все сервисы на малом ядре, пострадает качество и скорость работы приложений на переднем плане. Чтобы при таких сценариях работы она не замедлялась на архитектурах big.LITTLE, Windows отслеживает вызовы приложения, поступающие к другим процессам, чтобы выполнять работу от их имени. В таком случае мы выдаём приоритет переднего плана потоку, относящемуся к сервису, и заставляем его выполняться на большом ядре.
На этом позвольте закончить первую статью о ядре Windows, дающую обзор работы планировщика. Статьи со сходными техническими подробностями о внутренней работе ОС последуют позже.
Не многие знают, как посмотреть сколько ядер и потоков в установленном на компьютере процессоре под управлением Windows 10. Операционная система позволяет узнать количество ядер как с использованием стандартных средств, так и стороннего программного обеспечения. После подробных характеристик процессора можно оценить, подходит ли компьютер для игры по минимальным требованиям или нет.
Эта статья расскажет, как узнать сколько ядер в процессоре на Windows 10. Ответить точно, сколько ядер процессора нужно для игр не можно, поскольку разные проекты получают разные требования и оптимизацию. Только сейчас стало возможным в некоторых играх ощутить преимущества многоядерных процессоров благодаря хорошей оптимизации.
Как узнать сколько ядер в процессоре
Основные сведение о компьютере
Перейдите в Свойства компьютера нажав сочетание клавиш Win+Pause&Break. В открывшемся окне напрямую не указывается количество ядер процессора. На примере установленного процессора можно узнать количество ядер непосредственно с его названия (Eight-Core Processor — восьмиядерный процессор). Бывает в названии процессора указывается количество ядер, как Х4 или Х6, в зависимости от модели процессора.
Перейдите в раздел Параметры > Система > О системе. В обновлённом интерфейсе указываются все характеристики компьютера, которые можно увидеть ранее. Непосредственно с названия устройства определяем сколько ядер в установленном в компьютере процессоре.
Приложение сведения о системе
В обновлённом поиске введите Сведения о системе и выберите Запуск от имени администратора. В главном окне открывшего приложения найдите элемент Процессор и посмотрите его значение.
На примере AMD FX(tm)-9370 Eight-Core Processor можно увидеть количество ядер: 4, логических процессоров: 8, хотя в названии процессора указывается значение: 8 физических ядер. Можно предположить, что такие значения указываются из-за своеобразной архитектуры процессора. Но как не странно при правильной оптимизации игровых проектов такой мощности более чем достаточно.
Классический диспетчер задач
Перейдите в диспетчер задач нажав сочетание клавиш Ctrl+Shift+Esc. Классический диспетчер задач в актуальной версии операционной системы можно открыть и другими способами. В открывшемся окне перейдите в закладку Производительность и посмотрите сколько Ядер и Логических процессоров доступно на установленном процессоре.
Стандартная командная строка
В поисковой строке наберите Командная строка, и выберите пункт Запуск от имени администратора. В открывшемся окне выполните команду: WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors.
Диспетчер устройств в системе
Откройте диспетчер устройств выполнив команду devmgmt.msc в окне Win+R. Теперь перейдите в Процессоры, и посмотрите сколько отображается пунктов (потоков процессора).
В диспетчере устройств можно узнать количество потоков процессора, в случае линейки AMD FX(tm)-9370 количество ядер равно количеству потоков исходя из официальных характеристик устройства (не будем углубляться в подробности построения самого процессора). Здесь отображаются все другие подключённые устройства. Например, можно также узнать, какая видеокарта или процессор стоит на компьютере.
Средство конфигурации системы
О приложении конфигурации системы мы более подробно вспоминали в инструкции: Как зайти в MSConfig Windows 10. Не рекомендуется вносить изменения в конфигурацию системы без ознакомления с описанием каждого параметра.
Выполните команду msconfig в окне Win+R. Перейдите в раздел Загрузка > Дополнительные параметры и после активации пункта Число процессоров можно в ниже представленном списке посмотреть сколько ядер процессора доступно пользователю.
Не применяйте изменения после выбора любого значения, поскольку текущий пункт был создан для ограничения производительности. Вместе со средствами операционной системы можно использовать стороннее ПО. Его использовали для просмотра характеристик компьютера на Windows 10. К самым известным классическим программам относят: CPU-Z, AIDA64 и EVEREST Ultimate Edition.
А также непосредственно современный BIOS материнской платы позволяет ограничить производительность процессора, а значит и можно узнать сколько ядер в установленном процессоре. Для более надёжного и подробного ознакомления с характеристиками процессора рекомендуется посмотреть спецификации на сайте производителя.
Существует много способов узнать сколько ядер в процессоре на Windows 10. Стоит различать значения физических ядер и логических потоков. Поскольку сейчас на рынке есть множество процессоров с разными соотношениями ядрам к потокам. Интерес пользователей сейчас притянут к процессорам с увеличенному количеству потоков в два раза.
Многие начинающие пользователи часто интересуются вопросами производительности своего компьютера или ноутбука и хотят проверить характеристики “железа”. Процессор является главнейшей часть ПК, наряду с ОЗУ и видеокартой. В этой статье мы рассмотрим, как узнать все основные его характеристики (количество ядер/потоков, частота и т.д.) в Windows 10.
Как узнать сколько ядер процессора через “диспетчер задач”?
Существует просто огромное количество способов узнать эти сведения. Начнём с самых простых:
- На клавиатуре своего устройства зажимаем клавиши “Ctrl+Shift+Esc”.
- Запустится окно диспетчера задач. Нам следует перейти во вкладку “ Производительность”.
- В подпункте “Цп”, который открывается по умолчанию будут указаны все данные о компоненте, а именно: частота, число ядер и потоков, объёмы кэша всех уровней и т.д.
Интересный факт! В данном окне отображается загруженность процессора в реальном времени, в виде удобного графика.
Через командную строку Windows 10
- В поиске виндовс прописываем фразу “cmd”.
- В правой колонке выбираем “Запуск от имени администратора”.
- Запуститься сама командная строка. Здесь нам нужно ввести команду “WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors”.
Готово! Отображение информации здесь не очень удобный, но все сведения о количестве ядер и логических процессоров в “камне” — полностью верны.
Как посмотреть сколько ядер через диспетчер устройств?
В диспетчере устройства содержится вся информация о всех компонентах, установленных в вашем ПК/ноутбуке.
Отобразится целый список различных компонентов, которые вместе о составляют процессор. Сколько этих “компонентов” будет показано — столько ядер в процессоре.
Обращаемся за помощью к сторонним программам
Если вы предпочитает работать в среде стороннего софта для windows 10, то это отличный вариант для вас. В интернете можно найти спектр программ, которые выдадут вам все данные о том сколько ядер в вашем процессоре. Самые популярные из них:
Читайте также: