Що робить непрацездатний процес процесора?

Подивившись на джерело, straceя знайшов використання прапора-клона, CLONE_IDLETASKякий описується як:

#define CLONE_IDLETASK 0x00001000 /* kernel-only flag */

Заглянувши в нього глибше, я виявив, що, хоча цей прапор не висвітлений, man cloneвін фактично використовується ядром під час завантажувального процесу для створення непрацюючих процесів (у всіх яких повинен бути PID 0) для кожного процесора на машині. тобто машина з 8 процесорами матиме щонайменше 7 (див. питання нижче) такі процеси "працюють" (примітки).

Тепер це призводить мене до пари запитань про те, що насправді робить цей "непрацюючий" процес. Моє припущення полягає в тому, що воно виконує операцію NOP постійно, поки не закінчується її часовий проміжок, і ядро ​​призначає реальний процес для запуску або призначення режиму очікування ще раз (якщо ЦП не використовується). І все-таки, це повна здогадка. Тому:

1. На машині з, скажімо, 8 процесорами буде створено 7 таких непрацюючих процесів? (і один процесор буде утримуватися самим ядром, поки робота з робочим простором користувача не працює?)

2. Чи справді непрацюючий процес є лише нескінченним потоком операцій NOP? (або цикл, який робить те саме).

3. Чи використання процесора (скажімо uptime) просто обчислюється тим, наскільки тривалий час роботи в режимі очікування на процесорі та скільки часу його не було протягом певного періоду часу?

_{PS Цілком ймовірно, що велика частина цього питання пов'язана з тим, що я не повністю розумію, як працює ЦП. тобто я розумію складання, часові рамки та переривання, але я не знаю, як, наприклад, процесор може використовувати більше або менше енергії залежно від того, що він виконує. Буду вдячний, якщо хтось може просвітити і мене.}

Завдання в режимі очікування використовується для обліку процесів, а також для зменшення споживання енергії. В Linux створюється одна неробоча задача для кожного процесора і блокується на цьому процесорі; всякий раз, коли на цьому процесорі немає жодного іншого процесу, завдання в режимі очікування планується. Час, витрачений на завдання в режимі очікування, відображається як "час простою" в таких інструментах, як top. (Пробіг обчислюється по-різному.)

Здається, Unix завжди мав певний цикл холостого ходу (але це не обов'язково фактичне завдання в режимі очікування, див . Відповідь Гілла ), і навіть у V1 він використовував WAITінструкцію, яка зупиняла процесор, поки не відбулося переривання (воно позначало "зачекайте на перервати »). Деякі інші операційні системи, зокрема, використовували цикли зайнятості, DOS, OS / 2 та ранні версії Windows. Вже досить давно центральні процесори використовували таку інструкцію "чекати", щоб зменшити споживання енергії та теплопродукції. Ви можете бачити різні реалізації непрацюючих завдань, наприклад, в arch/x86/kernel/process.cядрі Linux: основна лише викликаєHLT, Який зупиняє процесор , поки не відбудеться переривання (і дозволяє C1 режим економії енергії), інші реалізації обробки різних помилок або неефективності ( наприклад , використовуючи MWAITзамість того , HLTна деяких процесорах).

Все це повністю відокремлено від режимів очікування в процесах, коли вони чекають події (введення / виведення тощо).

У дизайні підручника планувальника процесів, якщо у планувальника немає жодного процесу для планування (тобто якщо всі процеси заблоковані, очікуючи на введення), тоді планувальник чекає перерви процесора. Переривання може вказувати на вхід з периферійного пристрою (дія користувача, мережевий пакет, завершене зчитування з диска тощо) або може бути переривом таймера, який запускає таймер у процесі.

Планувальник Linux не має спеціального коду для випадків, коли нічого не потрібно робити. Натомість він кодує справу, що нічого не робиться, як особливий процес, неробочий процес. Процес простою планується лише тоді, коли жоден інший процес не планується (він фактично має нескінченно низький пріоритет). Процес очікування насправді є частиною ядра: це нитка ядра, тобто потік, який виконує код у ядрі, а не код у процесі. (Точніше, є одна така нитка для кожного процесора.) Коли запущений процес запуску, він виконує операцію очікування на переривання.

Як працює режим очікування на перерву, залежить від можливостей процесора. З найпростішим дизайном процесора, це просто зайнятий цикл -

nothing:
    goto nothing

Процесор постійно продовжує виконувати інструкцію гілки, яка нічого не досягає. Більшість сучасних ОС не роблять цього, якщо вони не працюють на процесорі, де немає нічого кращого, а більшість процесорів мають щось краще. Замість того, щоб витрачати енергію, не роблячи нічого, крім обігріву приміщення, в ідеалі процесор слід вимкнути. Таким чином, ядро ​​запускає код, який наказує процесору самому вимикатися або принаймні вимикати більшу частину процесора. Повинно бути принаймні одна невелика частина, яка залишається включеною, контролер переривання. Коли периферія викликає перерву, контролер переривання надсилає сигнал пробудження до основної (частини) процесора.

На практиці сучасні процесори, такі як Intel / AMD і ARM, мають безліч складних налаштувань управління потужністю. ОС може оцінити, скільки часу процесор буде перебувати в режимі очікування і вибере різні режими низької потужності залежно від цього. Режими пропонують різні компроміси між енергоспоживанням у режимі очікування та часом, необхідним для входу та виходу з режиму очікування. У деяких процесорах ОС також може знизити тактову частоту процесора, коли виявить, що процеси не вимагають багато процесорного часу.

Ні, незадіяне завдання не витрачає цикли процесора. Планувальник просто не вибирає непрацюючий процес для виконання. Процес очікування очікує, що відбудеться якась подія, щоб вона могла продовжуватися. Наприклад, він може чекати введення в read()системний виклик.

До речі, ядро ​​- це не окремий процес. Код ядра завжди виконується в контексті процесу (ну, за винятком спеціального випадку потоку ядра), тому сказати "невірно", і одне ЦП буде утримуватися самим ядром, поки робота з простором користувача не виконуватиметься ".