OSDev

Реален ли сабж?

_________________
Found a CPU. LAPIC ID: 00

Нет, поскольку к памяти (ОЗУ) процессор по определению имеет прямой доступ, а к любым удалённым устройством такового нет. Естественно, можно эмулировать прямой доступ: запретить доступ к соответствующим страницам, ловить прерывания по попыткам обращения к ним и эмулировать выполнение сбойнувшей команды, обращаясь за данными по сети. Но это и изврат, и крайне низкая производительность одновременно.

Особенно прикольно будет при длительном времени ответа. Даже внутри одной локалки на небольших расстояниях время ответа может быть до 100 миллисекунд. Если перед чтением/записью каждых 1-4 байт будет проходить 100мс...

У меня ядро - что-то вроде Л4 (есть отличия, но в данном случае это не важно). Я хочу изначально построить АПИ ядра так, чтобы прикладным программам было все равно работают ли они на одной машине или на разных. (Понятно, что это нельзя сделать для всех механизмов, но можно для основных).
Разделяемая память нужна, главным образом, для реализации pipes (если встроенных нет). pipes можно реализовать и с помощью сообщений, но это уж очень криво.
Что правильнее: предусмотреть в ядре примитив pipes или забить на pipes?
Или идея такой "сетевой ОС" вообще порочна?

_________________
Found a CPU. LAPIC ID: 00

Почему нет. Эта тема достаточно подробно исследована в 90-е годы. Опытные системы были, но до промышленных не дошло. Там где есть реальные задачи, слишком низкая скорость, что при наличии хорошего бюджета проекта проще решить дополнительной памятью. В общем - нет реального спроса. Для исследований - ИМХО очень интересная тема.

Вот навскидку нашел про Chorus:
http://www.leonard.nom.fr/publications/chorus/CS-TR-91-91.pdf

Посмотрите там "Related works" какие ещё системы можно посмотреть с таким способом организации памяти.

Вообще говоря, технически можно (а в хорошей ос даже желательно) виртуализировать любой вычислительный ресурс, в т.ч. адресные пространства процессов и их размещение на физических машинах. Другое дело, что для этого нужна соответствующая поддержка со стороны API системы. Надо только учитывать довольно серьёзные накладные расходы на передачу данных между машинами.
Когда я работал на серпуховском ускорителе (ИФВЭ), там был VAX-кластер. Т.е. куча физически раздельных VAX-11, которые были объединены в единый виртуальный кластер, представляющий собой кагбэ одну мощную виртуальную машину с единым файловым пространством и очередями задач. В принципе, можно привязать какую-то задачу к конкретной машине, но, как правило, этого не делалось. Запуская на недельку на исполнение задачу, я даже не знал (в смысле не задумывался), на какой конкретной машине она будет работать. Более того, если какой-то хост выключался (на прафилактику или ещё чего-то), задачи с него, фактически не прерывая своего выполнения, мигрировали на другие хосты.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

И уж во всяком случае нельзя навязывать виртуализацию: программист должен иметь возможность обращаться и к реальным ресурсам. Тогда, по крайней мере, можно будет писать критические ко времени задачи так, чтобы они гарантированно работали достаточно быстро.

Концептуально системы DSM выглядят отлично но работает действительно не очень - ну так в том и интерес довести их до рабочего состояния. Много вопросов с точки зрения миграции процессов, планирования их выполнения. Это область исследований в которой действительно можно искать и найти что-то новое, своё. А в очередной раз повторить существующую систему - скучно, а главное - результат такой работы будет никому не нужен.



А её никто не навязывает. Более того, в некоторых системах ядро (VMM) даже не знает о том, что есть DSM . В Mach например - это сделано через внешний пейджер. Если такой пейджер не подключен, то и памяти такой нет - всё самым привычным образом.

Я не являюсь специалистам по супер компьютерам. Но то что я знаю говорит о следующем.
Супер компьютер это группа серверов.
Сервер это стойка наполненная материнскими платами небольшими состоящих из 1-2 процессоров и планки памяти небольшого размера 512-1024 МБайта и всё это соединено 1ГБит/c Ethernet.
В таких машинах данные зачастую целиком находятся в памяти. Вот только они распределены.

Вывод напрашивается сам собой, системы с распределенной памятью более чем популярны. Хотя о проценте мне неизвестно.

По поводу задержек в Ethernet. Их можно свести к минимуму менее 1мс (к пимеру TCP_NODELAY). Вот только делать снижение задержки маленькими надо аккуратно, а тона производительности скажется отрицательно.

Это не суперкомпьютер, а кластер (распределённая вычислительная система, состоящая из нескольких компьютеров). То, что журнализды подобную конструкцию обзывают суперкомпьютером, ещё не значит, что оно таковым является.