Linux і симетрична багатопроцесорна система

1. Історія багатопроцесорної обробки
2. закон Амдаля
3. Малюнок 1. Закон Амдаля для розпаралелювання процесів
4. Малюнок 2. Закон Амдаля для системи, що має до десяти CPU
5. Многопроцессорная обробка і ПК
6. Слабосвязанних многопроцессорная обробка
7. Малюнок 3. слабо зв'язаної многопроцессорная архітектура
8. Сільносвязанная многопроцессорная обробка
9. Малюнок 4. Сільносвязанная архітектура багатопроцесорної обробки
10. Таблиця 1. Вибірка пристроїв CMP
11. конфігурація ядра
12. Лістинг 1. Використання файлової системи proc для отримання інформації про CPU
13. SMP і ядро ​​Linux
14. Потоки робочих просторів: розвиваючи силу SMP
15. Лістинг 2. Використання pthread_mutex_lock і unlock для створення критичних секцій
16. Захист змінної ядра для SMP
17. висновок
18. Ресурси для скачування

Розкрийте силу Linux в системах SMP

Швидкодію системи Linux ви можете збільшити різними способами, і один з найбільш популярних - збільшити продуктивність процесора. Очевидне рішення - використовувати процесор з більшою тактовою частотою, але для будь-якої технології існує фізичне обмеження, коли тактовий генератор просто не може працювати швидше. При досягненні цієї межі ви можете використовувати набагато кращий підхід і застосувати кілька процесорів. На жаль, швидкодія має нелінійну залежність від сукупності параметрів окремих процесорів.

Перш ніж обговорювати застосування багатопроцесорної обробки в Linux, давайте поглянемо на її історію.

Історія багатопроцесорної обробки

Многопроцессорная обробка зародилася в середині 1950-х в ряді компаній, деякі з яких ви знаєте, а деякі, можливо, вже забули (IBM, Digital Equipment Corporation, Control Data Corporation). На початку 1960-х Burroughs Corporation представила симетричний мультипроцессор типу MIMD з чотирма CPU, що має до шістнадцяти модулів пам'яті, з'єднаних координатним соединителем (перша архітектура SMP). Широко відомий і вдалий CDC 6600 був представлений в 1964 і забезпечував CPU десятьма подпроцессорамі (периферійними процесорами). В кінці 1960-х Honeywell випустив іншу симетричну мультипроцесорну систему з восьми CPU Multics.

У той час як багатопроцесорні системи розвивалися, технології також йшли вперед, зменшуючи розміри процесорів і збільшуючи їх здатності працювати на значно більшій тактовій частоті. У 1980-х такі компанії, як Cray Research, представили багатопроцесорні системи та UNIX®-подібні операційні системи, які могли їх використовувати (CX-OS).

В кінці 1980-х з популярністю однопроцесорних персональних комп'ютерів, таких як IBM PC, спостерігався занепад в багатопроцесорних системах. Але зараз, через двадцять років, многопроцессорная обробка повернулася до тих же самим персональних комп'ютерів у вигляді симетричною багатопроцесорної обробки.

закон Амдаля

Джин Амдаль (Gene Amdahl), комп'ютерний архітектор і співробітник IBM, розробляв в IBM комп'ютерні архітектури, створив однойменну фірму, Amdahl Corporation та ін. Але популярність йому приніс його закон, в якому розраховується максимально можливе поліпшення системи при поліпшенні її частини. Закон використовується, головним чином, для обчислення максимального теоретичного поліпшення роботи системи при використанні декількох процесорів (дивись Малюнок 1).

Малюнок 1. Закон Амдаля для розпаралелювання процесів

Використовуючи рівняння, показане на рисунку 1, ви можете вирахувати максимальне поліпшення продуктивності системи, що використовує N процесорів і фактор F, який показує, яка частина системи не може бути распараллелена (частина системи, яка є послідовною за своєю природою). Результат наведено на рисунку 2.

Малюнок 2. Закон Амдаля для системи, що має до десяти CPU

Верхня лінія на рисунку 2 показує число процесорів. В ідеалі це те, що ви хотіли б побачити після додавання додаткових процесорів для вирішення завдання. На жаль, через те що не всі в задачі може бути распараллеліть і є непродуктивні витрати в управлінні процесорами, прискорення виявляється трохи менше. Внизу (лілова лінія) - випадок завдання, яка на 90% послідовна. Кращому нагоди на цьому графіку відповідає коричнева лінія, яка зображує завдання, яка на 10% послідовна і, відповідно, на 90% - параллелізуема. Навіть в цьому випадку десять процесорів працюють зовсім не набагато краще, ніж п'ять.

Многопроцессорная обробка і ПК

Архітектура SMP - одна з тих, де два або більше ідентичних процесорів з'єднані один з одним за допомогою розділяється пам'яті. У всіх них однаковий доступ до пам'яті, що (однаковий час очікування доступу до простору пам'яті). Протилежністю їй є архітектура неоднорідного доступу до пам'яті (NUMA - Non-Uniform Memory Access). Наприклад, у кожного процесора є своя власна пам'ять і доступ до пам'яті, що з різним часом очікування.

Слабосвязанних многопроцессорная обробка

Ранні SMP системи Linux були слабо зв'язаної багатопроцесорними системами, тобто побудованими з декількох окремих систем, пов'язаних високошвидкісним з'єднанням (таким як 10G Ethernet, Fibre Channel або Infiniband). Інша назва такого типу архітектури - кластер (дивіться Малюнок 3), для якого популярним рішенням залишається проект Linux Beowulf. Кластери Linux Beowulf можуть бути побудовані з доступного обладнання і звичайного підключення до мережі, такого як Ethernet.

Малюнок 3. слабо зв'язаної многопроцессорная архітектура

Побудова систем зі слабо зв'язаної многопроцессорной архітектурою просто (спасибі проектам на кшталт Beowulf), але має свої обмеження. Створення великої многопроцессорной мережі може зажадати значних потужностей і місця. Більш серйозна перешкода - матеріал каналу зв'язку. Навіть з високошвидкісною мережею, такий як 10G Ethernet, є межа масштабованості системи.

Сільносвязанная многопроцессорная обробка

Сільносвязанная многопроцессорная обробка відноситься до обробки на рівні кристала (CMP - chip-level multiprocessing). Уявіть слабо зв'язаної архітектуру, зменшену до рівня кристала. Це і є ідея Сільносвязанная багатопроцесорної обробки (також званої багатоядерним обчисленням). На одній інтегральної мікросхемі кілька кристалів, спільна пам'ять і з'єднання утворюють добре інтегроване ядро ​​для багатопроцесорної обробки (дивіться Малюнок 4).

Малюнок 4. Сільносвязанная архітектура багатопроцесорної обробки

У CMP кілька CPU пов'язані спільною шиною з пам'яттю (кеш другого рівня). Кожен процесор також має свою власну швидкодіючу пам'ять (кеш першого рівня). Сільносвязанная природа CMP дозволяє дуже короткі фізичні відстані між процесорами і пам'яттю і, внаслідок цього, мінімальний час очікування доступу до пам'яті і більш високу продуктивність. Такий тип архітектури добре працює в багатопотокових застосуваннях, де потоки можуть бути розподілені між процесорами і виконуватися паралельно. Це називається паралелізм на рівні потоків (TPL - thread-level parallelism).

Беручи до уваги популярність цієї багатопроцесорної архітектури, багато виробників випускають пристрої CMP. В Таблиці 1 наведені деякі популярні варіанти з підтримкою Linux.

Таблиця 1. Вибірка пристроїв CMP

Виробник Пристрій Опис IBM POWER4 SMP, два CPU IBM POWER5 SMP, два CPU, чотири паралельні потоки AMD AMD X2 SMP, два CPU Intel® Xeon SMP, два або чотири CPU Intel Core2 Duo SMP, два CPU ARM MPCore SMP, до чотирьох CPUs IBM Xenon SMP, три Power PC CPU IBM Cell Processor Асиметрична многопроцессорная обробка (ASMP --Asymmetric multiprocessing), дев'ять CPU

конфігурація ядра

Для того щоб використовувати SMP з Linux на сумісному з SMP обладнанні, необхідно правильно налаштувати ядро. Опція CONFIG_SMP повинна бути включена під час налаштування ядра, щоб ядро ​​знало про SMP. Якщо таке ядро ​​буде працювати на многопроцессорном хості, ви зможете визначити кількість процесорів і їх тип за допомогою файлової системи proc.

Спочатку ви отримуєте число процесорів з файлу cpuinfo в / proc, використовуючи grep. Як видно з лістингу 1, ви використовуєте опцію - лічильник (-c) рядків, що починаються зі слова processor. Наведено також вміст файлу cpuinfo. Як приклад взята материнська плата Xeon на двох кристалах.

Лістинг 1. Використання файлової системи proc для отримання інформації про CPU

mtj @ camus: ~ $ grep -c ^ processor / proc / cpuinfo 8 mtj @ camus: ~ $ cat / proc / cpuinfo processor: 0 vendor_id: GenuineIntel cpu family: 15 model: 6 model name: Intel (R) Xeon (TM ) CPU 3.73GHz stepping: 4 cpu MHz: 3724.219 cache size: 2048 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 2 fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 6 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm pni monitor ds_cpl est cid xtpr bogomips: 7389.18 ... processor: 7 vendor_id: GenuineIntel cpu family: 15 model: 6 model name: Intel (R) Xeon (TM) CPU 3.73GHz stepping: 4 cpu MHz: 3724.219 cache size: 2048 KB physical id: 1 siblings: 4 core id: 3 cpu cores: 2 fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 6 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm pni monitor ds_cpl est cid xtpr bogomips: 7438.33 mtj @ camus: ~ $

SMP і ядро ​​Linux

Коли тільки з'явився Linux 2.0, підтримка SMP складалася з основної системи блокування, яка впорядковувала доступ в системі. Пізніше невеликий прогрес в підтримці SMP був, але тільки з ядром 2.6 нарешті проявилася вся сила SMP.

Ядро 2.6 представило новий 0 (1) планувальник, який включав кращу підтримку для систем SMP. Ключовий була можливість балансувати навантаження на всі доступні CPU, у міру сил уникаючи перемикання процесів між процесорами для більш ефективного використання кеша. Що стосується продуктивності кеша, згадайте з рисунка 4, що коли завдання взаємодіє з одним CPU, переміщення її на інший вимагає залучення кеша. Це збільшує час очікування доступу до пам'яті завдання, поки її дані знаходяться в кеші нового CPU.

Ядро 2.6 зберігає пару runqueue для кожного процесора (минулий і активний runqueue). Кожен runqueue підтримує 140 пріоритетів, з яких 100 використовується для задач в реальному часі, а решта 40 для користувача завдань. Завданням даються відрізки часу для виконання, а коли вони використовують свій час, вони переміщаються з активного runqueue в минулий. Таким чином здійснюється рівноправний доступ до CPU для всіх завдань (блокування тільки окремих CPU).

З чергою завдань на кожному CPU робота може бути збалансована, даючи зважену навантаження всіх CPU в системі. Кожні 200 мілісекунд планувальник виконує балансування завантаження, щоб перерозподілити завдання і зберегти баланс в комплексі процесорів. Більше інформації про планувальнику Linux 2.6 шукайте в розділі ресурси .

Потоки робочих просторів: розвиваючи силу SMP

У ядрі Linux була проведена велика робота для розвитку SMP, але операційної системи, самої по собі, недостатньо. Згадайте, що сила SMP полягає в TLP. Окремі монолітні (одно-потокові) програми не можуть використовувати SMP, але SMP може використовуватися в програмах, які складаються з багатьох потоків, які можуть бути розподілені між ядрами. Поки один потік чекає виконання операції I / O, інший може робити корисну роботу. Таким чином, потоки працюють, перекриваючи час очікування один одного.

Потоки стандарту Portable Operating System Interface (POSIX) (інтерфейс яку переносять операційної системи) є прекрасним способом побудувати потокові додатки, які можуть використовувати SMP. Потоки стандарту POSIX забезпечують механізм роботи з потоками, а також загальну пам'ять. Коли програма активізується, створюється деяка кількість потоків, кожен з яких підтримує свій власний стек (локальні змінні і стан), але розділяє простір даних батька. Всі створені потоки поділяють цей же самий простір даних, але саме тут криється проблема.

Щоб підтримувати багато-доступ до пам'яті, що, потрібні механізми координування. POSIX надає функцію взаємного виключення для створення критичних секцій, які встановлюють винятковий доступ до об'єкта (дільниці пам'яті) тільки для одного потоку. Якщо цього не зробити, може пошкодитися пам'ять через несінхронізованних маніпуляцій, вироблених кількома потоками. Лістинг 2 ілюструє створення критичної секції за допомогою взаємного виключення POSIX.

Лістинг 2. Використання pthread_mutex_lock і unlock для створення критичних секцій

pthread_mutex_t crit_section_mutex = PTHREAD_MUTEX_INITIALIZER; ... pthread_mutex_lock (& ​​crit_section_mutex); / * Всередині критичної секції. Доступ до пам'яті тут безпечний * для пам'яті, захищену crit_section_mutex. * / Pthread_mutex_unlock (& ​​crit_section_mutex);

Якщо кілька потоків намагаються заблокувати семафор після початкового виклику нагорі, вони блокуються, і їх запити ставляться в чергу, поки не виконається виклик pthread_mutex_unlock.

Захист змінної ядра для SMP

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

Визначення змінних окремого ядра проводиться за допомогою макросу DEFINE_PER_CPU, якому ви передаєте тип і ім'я змінної. Оскільки макрос надходить як l-value, тут же ви можете форматувати її. У наступному прикладі (з ./arch/i386/kernel/smpboot.c) визначається змінна, що представляє стан для кожного CPU в системі.

/ * State of each CPU. * / DEFINE_PER_CPU (int, cpu_state) = {0};

Макрос створює масив змінних, одну на кожен екземпляр CPU. Для отримання змінної окремого CPU використовується макрос per_cpu разом з функцією smp_processor_id, що повертає поточний ідентифікатор CPU, для якого в даний момент виконується програма.

per_cpu (cpu_state, smp_processor_id ()) = CPU_ONLINE;

Ядро надає інші функції для блокування кожного CPU і динамічного виділення змінних. Ці функції можна знайти в ./include/linux/percpu.h.

висновок

Коли частота процесора досягає своєї межі, для збільшення продуктивності зазвичай просто додають ще процесори. Раніше це означало додати більше процесорів до материнської плати або об'єднати в кластер кілька незалежних комп'ютерів. Сьогодні многопроцессорная обробка на рівні кристала надає більше процесорів на одному кристалі, даючи ще більшу швидкодію шляхом зменшення часу очікування пам'яті.

Системи SMP ви знайдете не тільки на серверах, а й на десктопах, особливо з впровадженням віртуалізації. Як багато передові технології, Linux надає підтримку для SMP. Ядро виконує свою частину по оптимізації завантаження доступних CPU (від потоків до віртуалізованних операційних систем). Все, що залишається, це переконатися, що додаток може бути в достатній мірі розділене на потоки, щоб використовувати силу SMP.

Ресурси для скачування

Схожі теми

• Оригінал цієї статті на developerWorks.
• " Усередині планувальника Linux (Inside the Linux scheduler) "Детально розповідає про новий планувальнику Linux, представленому в ядрі 2.6.
• " Стандартне використання Pthreads (Basic use of Pthreads) "Знайомить з програмуванням Pthread в Linux.
• " Отримайте доступ до ядра Linux за допомогою файлової системи / proc (Access the Linux kernel using the / proc filesystem) "Знайомить з файлової системою / proc, в тому числі пояснює, як побудувати свій власний модуль ядра, щоб забезпечити файл в файловій системі / proc.
• В " Історії паралельної обробки (The History of Parallel Processing) "(1998), Марк Пацифики (Mark Pacifico) і Майк Мерілл (Mike Merrill) дають коротку, але цікаву історію п'яти декад багатопроцесорної обробки.
• архітектури POWER4 і POWER5 компанії IBM передбачають симетричну многопроцессорную обробку. POWER5 крім того забезпечує симетричну многопоточность (SMT) для ще більшої швидкодії.
• процесор Cell має цікаву архітектуру для асиметричної багатопроцесорної обробки. Приклад Sony Playstation 3, яка використовує Cell, показує, яким потужним може бути цей процесор.
• IBM надає технології створення кластерів в Високодоступних многопроцессорной кластерної системі (High-Availability Cluster Multiprocessing) (HACMP). На додаток до мультипроцессорной обробці за допомогою кластерів, HACMP також забезпечує більш високу надійність за допомогою повного online моніторингу системи.
• Оригінальна класифікація Флінна визначала, що було можливо для багатопроцесорних архітектур. Його стаття називалася "Some Computer Organizations and Their Effectiveness." Вона була опублікована в IEEE Transactions on Computing, Том C-21, 1972. Wikipedia надає прекрасний конспект чотирьох класифікацій.
• ARM11 MPCore - процесор, здатний до з'єднання, який замінює чотири ARM11 CPU, виконуючи 2600 Dhrystone MIPS (млн. Інструкцій у секунду).
• кластер Beowulf - прекрасний шлях об'єднати звичайні сервера Linux для побудови високошвидкісних систем.
• Такі стандарти як HyperTransport , RapidIO і готується Common System Interconnect , Надають ефективні межсоединения кристал-в-кристал (chip-to-chip) для систем наступного покоління.
• В розділі Linux developerWorks Росія можна знайти більше ресурсів для розробників Linux.
• Свою наступну розробку в Linux створюйте з пробним ПО IBM , Доступним для скачування прямо з developerWorks.

Підпишіть мене на повідомлення до коментарів