Продуктивність мережі малої латентності InfiniBand на віртуальному кластері HPC HUB

areas
Моделювання складних фізичних процесів в наші дні розглядається як важлива технологічна можливість багатьма сучасними компаніями. Широко використовуваним зараз підходом для створення обчислювачів, здатних розраховувати складні моделі, є створення кластерних систем, де обчислювальний вузол являє собою сервер загального призначення, підключений до мережі малої латентності і керований своєї власної ОС (як правило, з сімейства GNU/Linux).

Введення віртуалізаційного шару в системне обчислювальних кластерів, дозволяє протягом декількох хвилин створювати «віртуальний кластер». Такі віртуальні кластера в рамках однієї OpenStack інфраструктури є абсолютно незалежними. Користувальницькі програми всередині них можуть бути змінені так, як потрібно користувачеві без будь-яких погоджень з ким-небудь, а логічні пристрої, на яких знаходяться дані, недоступні іншим віртуальним кластерів.

Підтримка мережі малої латентності виртуализационными рішеннями являє собою окрему складну проблему. Для прикладних програм, в більшості випадків сучасна віртуалізація на основі KVM призводить до мінімальних втрат обчислювальної потужності (<1%). Однак спеціалізовані тести мереж малої латентності показують накладні витрати від віртуалізації не більше 20% на операції синхронізації.

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

Набагато більш дешевим і широко використовуваним зараз альтернативним підходом є створення кластерних систем, де обчислювальний вузол представляє собою комп'ютер загального призначення, керований своєї власної ОС. При цьому обчислювальні вузли кластера синхронізуються і спільно управляються спеціальним ПО, що забезпечує запуск, супровід і зупинку так званих «паралельних програм». Останні являють собою незалежні процеси в ОС вузлів, синхронизирующихся один з одним за рахунок взаємодії в мережі. Далі ми будемо називати такі мережі «обчислювальними мережами», обчислювальні вузли — «кластерними вузлами» або просто «вузлами», керуюче ПО — «кластерний».

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

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

Наймасовішим стандартом API для створення сучасних паралельних додатків є MPI, існуючий в декількох реалізаціях. Також широко поширений стандарт Intel OpenMP API, призначений для створення паралельних програм в рамках однієї ОС на багатопроцесорному сайті. Оскільки сучасні кластерні вузли містять багатоядерні процесори з великим обсягом пам'яті, то можлива велика кількість варіантів визначення «обчислювача» в рамках парадигми розпаралелювання за даними і реалізації цієї парадигми на базі підходу паралельних програм. Найпоширенішими є два підходи:

  1. одне процесорне ядро — один обчислювач
  2. один багатопроцесорний вузол — один обчислювач

Для реалізації першого підходу досить використовувати MPI, для якого він власне і створювався. У рамках другого підходу часто використовується зв'язка MPI + OpenMP, де MPI використовується для комунікації між вузлами, а OpenMP для розпаралелювання всередині вузла.

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

Ключові характеристики обчислювальних мереж
Ключовими характеристиками спеціалізованих обчислювальних мереж є латентність і ширина каналу (швидкість обміну при великих обсягах даних). Швидкість передачі великих обсягів даних важлива для різних завдань, наприклад, коли вузлів треба передавати один одному результати, отримані на поточному кроці розрахунку, щоб зібрати початкові дані для наступного кроку. Латентність грає ключову роль при передачі повідомлень малого розміру, наприклад, синхронизационных повідомлень, необхідних для того, щоб вузли знали про стан інших вузлів, дані з яких їм потрібні. Синхронизационные повідомлення як правило дуже малі (типовий розмір декілька десятків байтів), але саме вони використовуються для запобігання логічних перегонів і тупиків (race condition, deadlock). Висока швидкість синхронизационных повідомлень власне відрізняє обчислювальний кластер від його найближчого родича — обчислювальної ферми, де мережа між вузлами не забезпечує властивості малої латентності.

Intel Infiniband є одним з найбільш масових стандартів мереж малої латентності сьогодні. Саме обладнання цього типу часто використовується в якості обчислювальної мережі для сучасних кластерних систем. Існує кілька поколінь Infiniband мереж. Найбільш поширений зараз стандарт Infiniband FDR (2011 рік). Як і раніше актуальним залишається стандарт QDR (2008 рік). Постачальниками обладнання зараз активно просувається наступний стандарт Infiniband EDR (2014 рік). Порти Infiniband як правило складаються з агрегованих груп базових двонаправлених шин. Найбільш поширені порти 4х.

Характеристики мережі Infiniband останніх поколінь
QDRx4 FDRx4 EDRx4
Повна пропускна здатність (Гбіт/c 32 56 100
Латентність порт-порт, мкс 1.3 0.7 0.7
Як відомо, віртуалізація вносить деякі свої специфічні затримки при роботі гостьових систем з пристроями. Не виняток у даному разі і мережі малої латентності. Але з-за того, що мала латентність (затримка) є їх найважливішою властивістю, взаємодія з виртуализациоными середовищами для таких мереж критично важливо. При цьому їх пропускна здатність, як правило, залишається такою ж, як і без віртуалізації в широкому діапазоні параметрів з'єднань. Важливим кроком у розвитку Infiniband, зробленим відносно недавно (2011 рік), є використання технології SR-IOV. Ця технологія дозволяє фізичний мережевий адаптер Infiniband перетворити в набір віртуальних пристроїв — віртуальних функцій VF. Такі пристрої, виглядають як незалежні Infiniband адаптери, наприклад, можуть бути віддані в монопольне управління різних віртуальним машинам або якимось высоконагруженным службам. Природно, що адаптери IB VF працюють за іншими алгоритмами, та їх характеристики відрізняються від оригінальних адаптерів IB без включеної підтримки SR-IOV.

Групові операції обмінів між вузлами
Як вже згадано вище, найпопулярнішим інструментальним HPC засобом на поточний момент залишається бібліотека MPI. Існують кілька основних варіантів реалізації MPI API:
Бібліотеки MPI містять основні функції, необхідні для реалізації паралельних обчислень. Критично важливими для HPC додатків є функції передачі повідомлень між процесами, особливо групові функції синхронізації та передачі повідомлень. Варто відзначити, що найчастіше під групою розуміються всі процеси паралельного застосування. У мережі легко знайти докладні описи MPI API:

Основи алгоритмів, використаних для реалізації MPI, добре описані в [1], також багато статей на цю тему можна знайти на посилання. Оцінки ефективності даних алгоритмів є предметом великої кількості робіт [2, 3, 4, 5]. Найчастіше оцінки будуються за допомогою методів асимптотичного аналізу теорії алгоритмів і оперують поняттями $t_s$ час встановлення з'єднання, $t_w$ швидкість передачі одиниці інформації, $m$ кількість переданих одиниць інформації, $p$ кількість задіяних процесорів.

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

Як легко зрозуміти, саме групові операції синхронізації є найбільш вимогливими до властивості «малої латентності» мережі і масштабованості цього властивості. Для наших тестів ми, як і інші автори [6], використовували наступні 3 операції:

broadcast
Найпростіша з групових операцій — broadcast (широкомовна розсилка). Один процес посилає одне і те ж повідомлення всім іншим (M позначає буфера з даними. Взято з [1]).
broadcast

В обчислювальних програмах broadcast часто застосовується для розповсюдження якихось умов, параметрів на початку рахунку та між ітераціями. Broadcast часто є елементом реалізації інших, більш складних колективних операцій. Наприклад, broadcast використовують у деяких реалізаціях функції barrier. Існують кілька варіантів алгоритмів для реалізації broadcast. Оптимальний час роботи broadcast на неблокирующем комутаторі повнодуплексних каналів без апаратного прискорення становить:
$t=(t_s + t_w m) log_2p$
all-reduce
Операція all-reduce проводить зазначену в параметрах асоціативну операцію над даними, що лежать в пам'яті групи обчислювачів, а потім повідомляє результат всім обчислювача групи. (Знак $\oplus$ означає зазначену асоціативну операцію. Взято з [1]).
all-reduce

З точки зору структури мережевих обмінів all-reduce аналогічна функції all-to-all broadcast. Ця операція застосовується для додавання або множення, пошуків максимуму або мінімумів серед операндів, розташованих на різних обчислювачах. Іноді ця функція використовується в ролі barrier. Оптимальний час роботи all-reduce на неблокирующем комутаторі повнодуплексних каналів без апаратного прискорення становить:
$t=(t_s + t_w m) log_2p$
all-to-all
Операцію all-to-all ще іноді називають «personalized all-to-all» або «total exchange». Під час цієї операції кожен обчислювач пересилає повідомлення кожному іншому вычислителю. Всі повідомлення можуть бути унікальними (Взято з [1]).
all-to-all

Ця операція інтенсивно використовується різними алгоритмами, такими як перетворення Фур'є, матричними перетвореннями, сортування, паралельними операціями над базами даних. Це одна з найбільш «важких» колективних операцій. Для даної колективної операції оптимальний алгоритм залежить від співвідношень значень ключових змінних $t_s$, $t_w$, $p$ і розміру переданих повідомлень $m$. При використанні алгоритму гіперкуба, який не є оптимальним за обсягом пересилок і застосовується для повідомлень малого розміру, оцінка часу становить:
$t = (t_s + t_w {pm \over 2}) log_2p$
Використовуються й інші підходи до тестування HPC середовищ. Наприклад, з допомогою інтегральних тестів, що імітують обчислення широко поширених завдань. Одним з найбільш популярних наборів інтегральних тестів є NAS parallel benchmarks. Цей тест також застосовувався і для тестування віртуальних HPC середовищ [7].

Методика тестування
Для тестів продуктивності, викладених в цій роботі, використовувалися сервера з процесорами Intel Xeon 64 Гб RAM і IB адаптерами ConnectX-3. На віртуальних і фізичних вузлах був встановлений OpenMPI, з'єднання вузол-вузол тестувалося з допомогою утиліт perftest і OSU benchmarks.

Більш докладноСервера сімейства Intel H2000JF (материнська плата S2600JF) з процесорами Intel Xeon E5-2680v2 2.8 GHz (10 ядер, HyperThreading вимкнений), 64 Гб оперативної пам'яті стандарту DDR3, IB адаптерами Mellanox Technologies MT27500 сімейства ConnectX-3 (firmware ConnectX3-rel-2_36_5000), з'єднаних через світч Mellanox SwitchX (36 портів SX6036 FDR).

OS CentOS Linux release 7.2.1511 (CentOS 7.2), ядро 3.10.0-327.18.2.el7.x86_64, qemu/KVM кастомизированный на базі 2.3.0 (в дистрибутиві CentOS 7 використовується версія 1.5.3 ), драйвера Mellanox OFED 3.3-1.0.4, qemu-kvm підтримував NUMA режим.

Гостьова OS CentOS Linux release 7.1.1503 (CentOS 7.1), ядро 3.10.0-229.el7.x86_64, драйвера Mellanox ConnectX-3. Кожна віртуальна машина була єдиною на своєму фізичному сервері і займала на ньому всі процесори і 48 Гб оперативної пам'яті, overcommit з процесорним ядрам був вимкнений.

Адаптери IB були переведені в режим підтримки SR-IOV, та було створено 2 VF на адаптер. Одна з VF експортувалася в KVM. Відповідно, у гостьовій OS було видно лише один адаптер Infiniband, а в хостової два: mlx4_0 і mlx4_1 (VF).

На віртуальних і фізичних вузлах був встановлений OpenMPI версії 1.10.3rc4 (входить до складу пакетів Mellanox OFED 3.3-1.0.4). З'єднання вузол-вузол тестувалося з допомогою утиліт perftest 0.19.g437c173.33100.

Групові тести проводилися з допомогою OSU benchmarks версії 5.3.1, зібраних з допомогою gcc 4.8.5 і зазначеного вище OpenMPI. Кожен результат OSU benchmarks є усередненням 100 або 1000 вимірювань, в залежності від ряду умов.
На фізичних вузлах демоном tuned встановлений профіль latency-performance. На віртуальних вузлах він був вимкнений.

Тести запускалися на двох вузлах (40 ядер). Вимірювання проводилися серіями по 10-20 вимірювань. В якості результату бралося середнє арифметичне трьох самих менших значень.

Результати
Наведені в таблиці параметри мереж є ідеальними, і в реальній ситуації вони недосяжні. Наприклад, латентність між двома вузлами з адаптерами Infiniband FDR (режим datagram), виміряна за допомогою ib_send_lat, становить для малих повідомлень 0.83 мкс, а корисна пропускна здатність (без урахування службової інформації) між двома вузлами, виміряна за допомогою ib_send_bw, становить 6116.40 МБ/с (~51.3 Гбіт/с). Пенальті за латентності і пропускної здатності в реальних системах обумовлена наступними факторами:
  1. додаткової латентністю комутатора
  2. затримками, зумовленими ОС вузлів
  3. втрати пропускної здатності на забезпечення передачі службової інформації протоколів
Запуск здійснювався на сервері командою:

ib_send_bw -F -a -d mlx4_0

на клієнта:

ib_send_bw -F -a -d mlx4_0 <server-name>

Так ib_send_lat між парою гостьових ОС, розташованих на різних фізичних серверах, показує латентність 1.10 мкс (зростання затримки на 0.27 мкс, ставлення латентностей нативного і виртуализированного IB становить 0.75), а ib_send_bw показує пропускну здатність у 6053.6 МБ/с (~50.8 Гбіт/с, 0.99 від корисної ширини каналу без віртуалізації). Дані результати знаходяться в хорошому згідно з результатами тестів інших авторів, наприклад [6].

Варто зауважити, що в хостової ОС тест працював не з SR-IOV VF, а з самим адаптером. Результати представлені трьома графіками:

  1. всі розміри повідомлень
  2. тільки повідомлення до 256 байтів включно
  3. ставлення часів виконання тесту для нативного Infiniband і для VF
Тест broadcast запускався і в хостової і гостьової ОС як:

/usr/mpi/gcc/openmpi-1.10.3rc4/bin/mpirun --hostfile mh -N 20 -bind-to core -mca pml ob1 -mca btl_openib_if_include mlx4_0:1 /usr/local/libexec/osu-micro-benchmarks/mpi/collective/osu_bcast

Найгірше ставлення часів — 0.55, для більшості тестів відношення не гірше 0.8.



Тест all-reduce запускався і в хостової і гостьової OS як:

/usr/mpi/gcc/openmpi-1.10.3rc4/bin/mpirun --hostfile mh -N 20 -bind-to core -mca pml ob1 -mca btl_openib_if_include mlx4_0:1 /usr/local/libexec/osu-micro-benchmarks/mpi/collective/osu_allreduce

Найгірше ставлення часів — 0.7, для більшості тестів відношення не гірше 0.8.



Тест all-to-all запускався і в хостової і гостьової OS як:

/usr/mpi/gcc/openmpi-1.10.3rc4/bin/mpirun --hostfile mh -N 20 -bind-to core -mca pml ob1 -mca btl_openib_if_include mlx4_0:1 /usr/local/libexec/osu-micro-benchmarks/mpi/collective/osu_alltoall

Найгірше ставлення часів — 0.87, для більшості тестів відношення не гірше 0.88.



Обговорення
Зубчаста форма представлених в тестах графіків з однієї сторони обумовлена результатом не дуже великий вибірки тестів, але з іншого боку є бажаним ефектом методу відбору найменших виміряних значень, що використовується при профілюванні програм. Обґрунтуванням цього методу є міркування, що фрагмент коду не може здійснитися швидше своєї максимальної швидкості, а всі процеси, які можуть відбуватися в системі одночасно з виконанням тестового коду, або не впливають на його швидкість, або уповільнюють його. Наявність здаються суперечливими результатів, коли віртуалізований тест виконується трохи швидше (2-5% прискорення), ніж невиртуализированный слід віднести до особливостей драйверів і прошивки IB адаптерів, які, по-перше, мають свої оптимізаційні схеми, а по-друге, все ж трохи по-різному працюють в обох випадках (розміри буферів даних, особливості обробки переривань і т. д.).

Особливості сучасних технологій віртуалізації вносять додаткові джерела затримок у порівнянні з ситуацією, де віртуалізаційного шару немає. До істотними для HPC можна віднести три види таких затримок:

  • Уповільнення швидкості роботи мережі малої латентності. У нашому конкретному випадку — уповільнення Infiniband в режимі віртуальної функції SR-IOV. Це затримка є центральною темою даної роботи і розібрана вище.

  • Зовнішні по відношенню до віртуалізаційного оболонці програми і служби будуть епізодично вимагати процесорного часу, будуть скидати кеші рахункових додатків. Це досить складним чином буде вносити різноманітну рассинхронизацию і затримки в рахункові програми, що працюють під віртуалізаційного оболонкою. Такі систематичні перешкоди можуть бути вкрай неприємні для всякого роду «екстремальних» програм, або неправильно оптимізованих. Зрозуміло варто розуміти, що без віртуалізаційного прошарку рахункові програми будуть працювати швидше. Проте в більшості практично важливих випадків пенальті по продуктивності за наявності керуючого коду поза віртуалізаційного оболонки на сучасних багатоядерних вузлах не перевищує кількох відсотків, а найчастіше воно <1%. До того ж існує ряд підходів, які дозволяють виділити і зафіксувати процесорні ядра, які будуть займатися навантаженнями поза віртуалізаційного оболонки, виключивши їх з віртуалізованої середовища. В результаті вплив на процесорні ядра та їх кеші всередині віртуалізаційних оболонок можна мінімізувати.

  • При роботі з віртуальним APIC виникають численні виходи в гіпервізор, що дуже накладно по затримці (десятки мікросекунд). Ця проблема стала актуальною останнім часом у зв'язку зі зростанням запитів на багатоядерні віртуальні машини, і їй приділяється увага на різних конференціях і в спеціалізованих виданнях, наприклад [8,9]. Такі затримки відбуваються при доставці переривань, в тому числі і від SR-IOV пристроїв (у нашому випадку Infiniband) в гості, і при пробудженні ядра процесора зі сплячого стану (IPI), наприклад, при отриманні повідомлення
Найбільш радикальними методами зменшення віртуалізаційних пенальті для обробки переривань, на погляд авторів, є або використання процесорів Intel з підтримкою vAPIC, або використання контейнерної віртуалізації (наприклад LXC) для рахункових вузлів. На суттєвість затримки, що виникає при обробці переривань у KVM, також побічно вказується в [7], де автори встановлюють зв'язок між зростанням кількості переривань та суттєвим зменшенням продуктивності віртуалізованої версії тесту.

Оцінити дані затримки, крім самої першої, з допомогою простих формул, подібних наведеним в [1], складно з кількох причин:

  • Перша і основна з них та, що дані затримки проявляються асинхронно з алгоритмом рахункової задачі, яка працює у віртуалізованому середовищі
  • Друга причина полягає в тому, що дані затримки залежать від «історії» обчислювального вузла в цілому, включаючи і алгоритм рахункової завдання і ПО віртуалізації — стану кешей, пам'яті, контролерів
Також важливо розуміти, що при пересиланнях великої кількості пакетів по мережі малої латентності, зокрема, при фрагментації великих повідомлень, швидкість генерації переривань буде зростати по складному закону, що може призвести до появи неортодоксальних залежностей швидкості передачі повідомлень від їх довжини і знову ж таки, історії стека ПО віртуалізації.

Творцями традиційних кластерних обчислювальних систем докладаються величезні зусилля, щоб усунути перешкоди для обчислювальних завдань:

  • вимикання непотрібних служб ОС
  • мінімізація всіх мережевих обмінів
  • мінімізація будь-яких інших джерел переривань для вузлів
У разі поєднання віртуалізації і хмарного ми знаходимося лише на початку цього шляху оптимізації під високопродуктивні обчислення.

Висновки
Порівняльні тести набору з трьох часто використовуваних операцій MPI (broadcast, all-reduce, personalized all-to-all) показали, що виртуализационная середовище на базі qemu/KVM і з використанням технології SR-IOV демонструє збільшений час тестів в середньому на 20% (у гіршому випадку-на 80% при broadcast пакетів розмірами 16 і 32Кб). Дане падіння продуктивності хоча і помітно, однак не критично для більшості паралельних додатків, пов'язаних з механікою суцільних середовищ, молекулярною динамікою, обробкою сигналів і т. д. Зручність використання віртуальному середовища, можливість швидкого розширення обчислювального поля і його налаштування кратно компенсує витрати на можливе збільшення рахункового часу.

Для завдань, що вимагають швидкого випадкового доступу одного вузла в пам'ять іншої, така затримка може бути критичною. Швидше за все вона не дозволить ефективно використовувати віртуалізовані кластера для вирішення подібних завдань.

На практиці деградація продуктивності обчислювальних програм часто виявляється набагато менше зазначених величин (max 20%). Це відбувається тому, що більшість часу добре написані і широко використовувані програми все ж вважають і обробляють дані всередині обчислювача, а не здійснюють операції синхронізації або пересилання даних. Адже автори паралельного коду завжди прагнуть вибрати такі алгоритми та прийоми реалізації, які мінімізують потреба в синхронізації і пересилках між обчислювачами.

Література
Більш докладно
  1. A. Grama, A. Gupta, G. Karypis, V. Kumar. Introduction to Parallel Computing, Second Edition. Addison-Wesley, 2003
  2. R. Thakur, W. Gropp. Improving the Performance of Mpi Collective Communication on Switched Networks, 2003

  3. R. Thakur, R. Rabenseifner, W. Gropp. Optimization of Collective Communication Operations in MPICH. Int'l Journal of High Performance Computing Applications,-- 2005 — Vol 19(1) — pp. 49-66.
  4. J. Pješivac-Grbović, T. Angskun, G. Bosilca, G. E. Fagg, E. Gabriel, J. J. Dongarra. Performance analysis of MPI collective operations. Cluster Computing — 2007 — Vol. 10 — p.127.
  5. B. S. Parsons. Accelerating MPI collective communications through hierarchical algorithms with flexible inter-node communication and imbalance awareness. Ph. D. Thesis on Computer science, Purdue University, USA, 2015
  6. J. Jose, M. Li, X. Lu, K. C. Kandalla, M. D. Arnold, D. K. Panda. SR-IOV Support for Virtualization on InfiniBand Clusters: Early Experience. International Symposium on Cluster, May 2011
  7. A. Kudryavtsev, V. Koshelev, A. Avetisyan. Modern HPC cluster virtualization using KVM and Palacios. High Performance Computing (HiPC) Conference, 2012
  8. D. Matlack. KVM Message Passing Performance. KVM forum, 2015
  9. R. van Riel. KVM vs. Message Passing Throughput, Reducing Context Switching Overhead. Red Hat KVM Forum 2013

Матеріал підготовлений Андрієм Ніколаєвим, Денисом Луньовим, Ганною Субботіної, Вільгельмом Бітнером.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.