Что использовать для создания 1 виртуального процессора на базе двух физических?

Я хочу вместо 2 процессоров, по 12 ядер, работать с 1 процессором по 24.

Но нафига? NUMA всё равно никуда не денется.

А мне, пожалуйста, единорога.

Но нафига?

Некоторые многопоточные программы не умеют работать с двумя процессорами и будут грузить только один процессор. С одним виртуальным устройством, по задумке они будут грузить все ядра.

не умеют работать с двумя процессорами

Пример такой программы в студию. Что-то платное за много денег с оплатой по числу физических процессоров?

Тоже виртуального? На базе физической лошади и носорога?

Лучше на базе физической лошади и резинового члена.

Ставишь виртуалку, выделяешь ей все настоящие процы, а виртуальный проц моделируешь как тебе нужно. Но зачем это - непонятно. Если софт почему-то отказывается работать на отдельных процах, то он либо вредительский (и его надо выкинуть), либо действительно есть серьёзные причины так не делать. Впрочем, если он опенсорс то можно отключить проверку, но сначала разобраться зачем она там есть и чем ты рискуешь.

Для киберкурвы не поможет

Но нафига? NUMA всё равно никуда не денется.

Если включить чередование памяти — NUMA превратится в UMA. Это можно как глобально настройками бивиса сделать, так из самой ОС для конкретной софтины через numactl включить. Естественно со всеми вытекающими последствиями в виде усреднения времени доступа и загруженной межпроцессорной шиной.

И кстати многоголовость вовсе не всегда означает NUMA. Вот у меня предыдущая станция была NUMA, а та что сейчас — нет. Архитектурно она NUMA, но таблиц соответствующих в ACPI нет, чередование банков неотключаемое, а сокетов меж тем два.

Ты хочешь что-то очень странное, два физических проца и два ядра одного проца для программы равны между собой. Если программа умеет использовать многопоточность то она одинаково сможет их использовать. Но если программа работает в один поток, но имеет поддержку mpi, то можно использовать опять же все ядра этой машины, а заодно и ядра другой машины через средства mpi. Чаще всего это расчётные программы и в их мануале указано как это делать. Тот же ансис имеет блокировку на уровне лицензии на 4 проца/ядра/потока для студенческой лицензии.

Некоторые многопоточные программы не умеют работать с двумя процессорами и будут грузить только один процессор. С одним виртуальным устройством, по задумке они будут грузить все ядра.

Во первых это бред, а во вторых никто не мешает тебе прибить конкретный софт к конкретным ядрам с конкретными их номерами. Называется processor affinity, рулится через numactl (прибивание к ядрам работает и без NUMA, просто в этом случае у тебя как бы одна единственная NUMA нода, управление памятью в этом случае теряет смысл, а управление процессорами\потоками по прежнему применимо), либо через утилиту taskset.

Подробнее тут: https://www.baeldung.com/linux/process-set-processor-affinity.

Напоследок добавлю, что планировщик процессов в ядре замечательно разбирается где сокет, где ядро, на каком сокете, а так же где у ядер гипертред. И иерархию кешей учитывает. И вполне самостоятельно раскидывает задачи оптимальным образом с учётом всей этой тряхомудии, как в варианте с NUMA, так и с UMA.

Это я тебе говорю как человек не первый десяток лет на практике использующий многоголовые рабочие станции и сервера. У меня ещё тыщщу лет назад были сервера с двумя и более пнями про и рабочая станция на двухслотовом асусе p2b-ds с двумя пнями II. Так что я лично наблюдал весь процесс развития и поддержки многоголовых и многоядерных конфигураций ядром линукс.

Если включить чередование памяти — NUMA превратится в UMA

Ага, роняем производительность в угоду простоте.

Ага, роняем. Я же не говорю что это нужно делать, я говорю что это можно делать. Ну и иногда так сделано изначально и не отключается, так тоже бывает.

Киберкурва кстати шикарно размазывается по двум сокетам и 32 потокам (из которых половина гипертред конечно). У движка курвы всё прекрасно с масштабированием и многопотоком.

Но да, есть игры которым больше восьми ядер лучше не давать, они больше чем с восемью не справляются, и начинаются прыжки по ядрам и сокетам, а так же микрофризы. Я такие через numactl гвоздями приколачиваю к восьми физическим ядрам одного сокета пропуская гипертредовые «половинки».

Ещё бывает что у самой игры плохо с избыточными ядрами, но хорошо с гипертредом, она понимает что это такое и в движке грамотно использует. Такие лучше работают будучи прибитыми к четырём физическим и соответствующим им четырём виртуальным ядрам в одном сокете.

Киберкурва кстати шикарно размазывается по двум сокетам и 32 потокам (из которых половина гипертред конечно). У движка курвы всё прекрасно с масштабированием и многопотоком.

Определение «прекрасно» в студию. Многопоток там есть, типа лучше чем ничего. Но выжать 60 кадров с лучами на Рыжем 1700 было невозможно, проц недогружен, видяха недогружена. 30-40 в плохой сцене

Хммм. Видел другую задачу: представить ~1000 физических машин как одну логическую с много CPU.

Например, чтобы не морочиться с очередями PBS, а прозрачно запустить make -j1000 …

https://ru.wikipedia.org/wiki/MOSIX оно?

Берешь QEMU (VirtualBox, VMWare Workstation, etc). Настраиваешь, что система использует 23 (22) процессора. (1 (2) на хост системе остается для эмуляции)

Спасибо, оно, но таки хочет немножечько шекелей.

Из открытого были OpenMOSIX и OpenSSI, привязанные к ядрам 2.4/2.6 и заброшенные.

В Plan 9 это было by design, но оно не POSIX.

Почему-то лет 25-15 назад SSI-проекты остановились. Вместо этого стали лепить job oriented middleware из гомна и палок.

юпапаюпаать…. с помощь ВИРТУАЛЬНОЙ МАШИНЫ. гуглить kvm install ubuntu how-to в конфиги ставишь мануальная топология архитехтуры, и ставишь себе ядер сокетов потоков сколько захочешь, можешь даже выбрать ченить отличное от х86. Накой х оно тебе понадобилось незнаю и знать не хочу. развлекайся.

ну если посмотреть на накладные расходы на переезд процесса с гигами так 20 памяти между нодами SSI кластера - становится понятно, почему проекты остановились…

ровно поэтому к слову сейчас серверные процессоры - огромные лапти c 8+ каналами памяти и 128+ ядрами, вместо того чтобы делать плату на 8-16 голов.

если посмотреть на накладные расходы на переезд процесса с гигами так 20 памяти между нодами SSI кластера - становится понятно, почему проекты остановились…

Есть задачи, в которых не надо мигрировать процессы. Достаточно прозрачно запускать новые на свободных нодах.

P.S. Делал для одного частного случая обертку к PBS, но это костыль.