Можно ли создать виртуальное ядро в Linux, если имеется кластер ARM?
======================================================================

 К восьми портовому коммутатору я подключил 1 провод от роутера, 1 провод к ноутбуку, и 6 проводов к Orange Pi Zero Plus, на которых стоят процессоры Alwinner H5, 4 ядра по 1,44 ггц. Задаюсь вопросом о снятии нагрузки с ноутбука под управлением Linux. Когда речь заходит о кластеризации, то возникает вопрос, как перенести выполняющиеся задачи на эти микрокомпьютеры. Все сетевые интерфейсы 1Gb/s.   

Я понимаю, что кластеры используют под определенные задачи, когда есть вебсервис, который много считает к примеру. Дело в том, что я не хочу привязывать ноутбук к одному месту. Но когда я дома - хочу подключать провод и снимать нагрузку с процессора, может быть с озу. Если научить linux обращаться по правильному адресу и перенаправить поток данных на обработку в кластер. Что выгоднее для процессора ноутбука, самому посчитать, или же передать на обработку в кластер. Я так подумал, у кластера получается 6*4=24 ядра по 1,44ггц, у моего ноутбука 2 ядра по 1,5ггц без Intel HT. Можно избавиться от тяжелых процессов если управлять задачами. К примеру мой локальный сервер видит нагрузку всех ARM linux'ов и запускает обработку на свободных. Но сделать это как - еще не понял. Хотелось бы понять, как линукс понимает что у него 2ядра, или 2 ядра и 4 потока, как он понимает, что у него 2 intel xeon на одной плате, можно ли в то же самое место монтировать ядра из ARM?  

  

Мне очень интересно ваше мнение по этому поводу, буду рад любым идеям, что можно предпринять . 

 Работать будет только на тех задачах которые вы реализуете.  

Из описания вы хотите какой-то магии с разгрузкой ноута от его задач, так работать не будет.  

Ядра с других машин нельзя никак "монтировать".  

Кластер, это несколько машин объединенных одной задачей и ПО которое распределяет конкретную задачу.  

Так же полезно будет знать следующую таблицу: <https://gist.github.com/jboner/2841832> 

 Ну во-первых, 1,5ггц на х86 и 1,5ггц на arm - две большие разницы, х86 будет быстрее. Хотя на задачах, которые хорошо параллелятся действительно можно выиграть за счет суммарного количества ядер.  

Во-вторых, даже если Вы придумаете как и напишите патч к ядру линукс, чтоб в определенных условиях некоторые процессы вместо запуска отправлялись по сети, то все равно, arm процессор не сможет выполнить код скомпилированный под x86\_64.  

  

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

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

А вот поверх этой виртуальной машины уже можно будет запустить хоть линукс, хоть фряху, и даже винду, если все же решим х86 эмулировать.  

Можете проспонсировать сию теорию, найду ребят которые за годик другой реализуют прототип этой идеи. 

 Кластеризация - это весьма многообразная и нетривиальная наука. Если многопроцессорные/многоядерные системы уже стали банальностью - то кластеризация "ещё не устаканилась".  

  

Есть вариант кластеризации, подражающий многопроцессорынм/многоядерным системам:  

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

Перенос задачи на новую ноду возможен только если там одинаковые процессоры (либо - если код задачи интерпретируемый; например, байт-код JVM).  

  

Как правило, многопоточные задачи не распределяют на несколько нод. Ибо потоки часто обмениваются данными через память - а синхронизировать память между нодами слишком дорого.  

  

Но есть и иной тип кластеризации:  

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

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

  

Кажется, я достаточно загрузил Вас. Дальше разговаривать надо после того, как Вы уточните - что за тяжёлые задачи Вы хотите распараллелить.