Мне нужно управлять памятью в отдельном пространстве памяти. Другая программа имеет большую плиту смежной памяти, которую мой код не может напрямую обращаться, и уведомляет мой код о его размере во время инициализации. Другая программа попросит мой код "выделить" X-байты из панели и позже уведомит мой код, чтобы освободить выделенные блоки. Отчисления и освобождение будут более или менее непредсказуемыми, так же как использование регулярного malloc
и free
. Это до моего кода для управления динамической памятью для другого процесса. Предполагаемое использование связано с памятью устройства на графическом процессоре, но я бы предпочел не задавать этот вопрос. Я бы хотел получить ответ, общий, может быть, даже достаточно, чтобы теоретически использовать его в качестве базового для сетевого API для управления виртуальной памятью на удаленной машине.
Основная функциональность, которая мне нужна, - это возможность инициализировать менеджер с размером панели, выполнить эквивалент malloc()
и free()
и получить несколько статистических данных, таких как оставшаяся доступная память и, возможно, максимальный выделяемый размер.
Очевидно, я не могу использовать malloc()
и free()
"абстрактно". Я также не хочу, чтобы управление моей фактической памяти процесса мешало управлению моей абстрактной плитой.
Какой был бы лучший способ сделать это? И, более конкретно, имеет ли стандартная библиотека или Boost такой вид объекта?
Заметки:
интерфейс для сетевого API для управления виртуальной памятью на удаленной машине
Сетевая система не должна заботиться об управлении памятью удаленного узла. Удаленный узел должен быть свободен в выборе того, следует ли обслуживать запрос, выделяя память в самой быстрой, но короткой памяти или в более крупном, но медленном хранилище или в гибриде как в зависимости от его собственной эвристики, так и с другими запросами, установленными одновременно, политикой установления приоритетов/политики безопасности администратором сети и т.д.
Мышление в терминах malloc и free ограничит то, что удаленный сервер может сделать для эффективного обслуживания запросов.
Обратите внимание: строго говоря, сам malloc управляет только "теоретической"/"виртуальной" памятью. Ядро ОС может печатать память страниц, выделенную с помощью malloc внутри и вне пространства подкачки, и назначать или перемещать свой физический адрес в MMU. "Адрес" памяти, возвращаемый "malloc", фактически представляет собой виртуальный адрес, который не соответствует фактическому физическому адресу.
В отличие от сетевой системы, при управлении оборудованием, которое вы обычно хотите очень точно диктовать то, что аппаратное обеспечение должно делать на каждом шаге, поскольку, по-видимому, аппаратное обеспечение подключается только к одной системе, поэтому любое утверждение является лишь локальным утверждением и соображениями относительно производительности пропускная способность обычно превосходит все остальное. Характер управления удаленным ресурсом в сетевой системе и локальном оборудовании аналогичен, но совершенно другой.
Если вам интересны проекты для сетевой общей памяти, вы можете проверить в памяти базы данных (например, Redis) или сетевые файловые системы. Сетевая разделяемая память обычно может позволить себе использовать удобные строковые ключи для указания на панели памяти; аппаратная общая память обычно хочет сохранить ее простой и быстрой, используя простые числовые дескрипторы.
Как сетевым, так и аппаратным средствам необходимо иметь дело с разделением одного ресурса для нескольких независимых процессов. Во многих популярных операционных системах код, ответственный за управление распределением оборудования, обычно является ядром. Это довольно редко для программы userpace, которая отвечает за управление оборудованием на монолитных ОС. Может быть, вы должны написать драйвер устройства? У многих устройств GPGPU теперь есть MMU.
Конечно, ничего не мешает вам писать gpu_malloc()
/gpu_free()
. Теоретически должно быть возможно mmap
удаленное системное адресное пространство в адресное пространство виртуальной памяти процесса, чтобы программы могли просто использовать удаленную память так же, как и любую другую память.
Я собираюсь использовать это для выделения между десятками и несколькими тысячами буферов в секунду с разными размерами; несколько таких же, как несколько байтов, размером до гигабайт.
Как правило, вы не хотите иметь тысячи небольших распределений. Системные вызовы, относящиеся к управлению памятью, могут быть дорогими, если они связаны с удаленными системами, поэтому может потребоваться, чтобы клиентская программа выделяла большие слябы и выполняла свое собственное вспомогательное распределение (malloc делает это, небольшие mallocs обычно заставляют один системный вызов выделять больше память, чем запрашивается, а malloc затем перекрывает панель).
malloc()
и free()
управляют виртуальной памятью; но я не спрашивал об управлении виртуальной памятью процесса ...
malloc
из slab и вернуть указатель, который A записывает и читает, и когда» это сделано, оно сообщает компьютеру B.free
указатель. Таким образом, компьютер B управляет отдельными выделениями из «плиты», хотя вся память фактически находится в виртуальной памяти A. Это странное прикосновение, но это имеет смысл.