LINUX.ORG.RU

История изменений

Исправление zaz, (текущая версия) :

какая разница, один хип у тебя или 50?

Большой разницы конечно нету, но это усложнает систему (сейчас есть статика есть 1 хип, а так будет локальный хип, хип для дискового I/O, хип для сетевого I/O и т.д). А просадка будет в том что хип подсистем (например хип для дискового I/O) будет иметь высоконкурентную нагрузку (много независимых процессов будут одновременно работать с ним), а как известно накладные расходы на межпотоковую синхронизацию увеличиваются с ростом конкурентности.

Да просто в RAII обернуть

Проблема не только в том что ПО может «потерять» буфер, например некий злоумишленик (студент на общем сервере в университете) запускает ПО которое специально (или по глупости) делает большое количество READ и не освобождает используемые буфера. Что делать в таком случае ? Наращивать IO heap пока модуль ввода/вывода не получит out-of-memory ? Для каждого процесса вести учет используемых буферов и ограничивать потребление памяти на вводе/выводе? (опять таки накладные расходы) + Нужно хранить списки буферов за каждым процессом (если процесс вдруг крашнулся нужно освободить все буфера которые были за ним закриплены).

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

Исправление zaz, :

какая разница, один хип у тебя или 50?

Большой разницы конечно нету, но это усложнает систему (сейчас есть статика есть 1 хип, а так будет локальный хип, хип для дискового I/O, хип для сетевого I/O и т.д). А просадка будет в том что хип подсистем (например хип для дискового I/O) будет иметь высоконкурентную нагрузку (много независимых процессов будут одновременно работать с ним), а как известно накладные расходы на межпотоковую синхронизацию увеличиваются с ростом конкурентности.

Да просто в RAII обернуть [/qoute] Проблема не только в том что ПО может «потерять» буфер, например некий злоумишленик (студент на общем сервере в университете) запускает ПО которое специально (или по глупости) делает большое количество READ и не освобождает используемые буфера. Что делать в таком случае ? Наращивать IO heap пока модуль ввода/вывода не получит out-of-memory ? Для каждого процесса вести учет используемых буферов и ограничивать потребление памяти на вводе/выводе? (опять таки накладные расходы) + Нужно хранить списки буферов за каждым процессом (если процесс вдруг крашнулся нужно освободить все буфера которые были за ним закриплены).

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

Исходная версия zaz, :

какая разница, один хип у тебя или 50?

Большой разницы конечно нету, но это усложнает систему (сейчас есть статика есть 1 хип, а так будет локальный хип, хип для дискового I/O, хип для дискового I/O и т.д). А просадка будет в том что хип подсистем (например хип для дискового I/O) будет иметь высоконкурентную нагрузку (много независимых процессов будут одновременно работать с ним), а как известно накладные расходы на межпотоковую синхронизацию увеличиваются с ростом конкурентности.

Да просто в RAII обернуть [/qoute] Проблема не только в том что ПО может «потерять» буфер, например некий злоумишленик (студент на общем сервере в университете) запускает ПО которое специально (или по глупости) делает большое количество READ и не освобождает используемые буфера. Что делать в таком случае ? Наращивать IO heap пока модуль ввода/вывода не получит out-of-memory ? Для каждого процесса вести учет используемых буферов и ограничивать потребление памяти на вводе/выводе? (опять таки накладные расходы) + Нужно хранить списки буферов за каждым процессом (если процесс вдруг крашнулся нужно освободить все буфера которые были за ним закриплены).

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