Можно ли поместить задания на чтение / запись в очередь?

Боб читает / пишет большие файлы (например, используя gunzip). Это может занять до 100% памяти, с перерывами, в течение нескольких часов. Обычно это делается в одночасье, но при запуске даже простые команды, такие как cd, занимают 30 секунд, а открытие emacs может занять несколько минут.

Первый gzip а также gunzip не работают так, как вы думаете - алгоритм, используемый gzip, основан на блоках, и, хотя он может быть немного больше при загрузке большого сжатого файла, даже при распаковке файла.gz размером 1 ГБ, потребляется всего около 15 МБ ОЗУ (всего размер процесса) на моей машине.

Во-вторых, если вы не загрузите весь файл в ОЗУ, простое чтение или запись большого файла не отнимут много памяти - ОС может хранить данные в кеше файловой системы, но данные кеша будут удалены, как только программа этого потребует. БАРАН. Только данные, хранящиеся в рабочей памяти программы, учитываются как "нагрузка на память" (используемая оперативная память, плюс или минус несколько других факторов).

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

Перестаньте пытаться перехитрить пейджер вашей операционной системы: ядро ​​поменяет задачи, чтобы гарантировать, что у того, кто в данный момент исполняет, есть оперативная память для работы. Да, это означает, что вы будете нажимать на диск, если используете больше оперативной памяти, чем у вас есть. Решение состоит в том, чтобы ограничить объем используемой оперативной памяти, запустив меньшее количество программ, или добавить больше оперативной памяти.

Концепция "резервирования" ОЗУ в корне ошибочна с точки зрения проектирования ОС: других действий не может быть, но программа Боба не может коснуться "зарезервированной" ОЗУ, поэтому теперь она должна идти и переключаться на диск. For want of (eg) 1KB, Bob's program is now making constant disk hits paging data in and out of RAM, and your performance goes through the floor.

You can artificially limit Bob's RAM usage (ulimit), но когда он достигнет жесткого предела, его программы, вероятно, будут плохо реагировать (подумайте: malloc(): Unable to allocate XXXXX bytes с последующим неблагодарным выходом).

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

В реальном мире Джефф, вероятно, прав: вы, вероятно, нарушаете ограничения дискового ввода-вывода, а не ОЗУ: распаковка файлов - это огромное количество дискового ввода-вывода (считывание сжатого файла, пропуск его через ЦП и небольшой объем данных). немного оперативной памяти, выплюнуть его в несжатый файл). nice (повлиять на приоритет процессора) и ionice если поддерживается (влияет на приоритет диска), то это облегчит вашу проблему.

лекция

Не зря, но я вспоминаю тот же вопрос из моего учебника по дизайну операционной системы (хотя пример не был gzip/gunzip). Хотя существует небольшая вероятность того, что вы действительно столкнетесь с этой проблемой в реальном мире, у меня есть свои сомнения: это просто слишком надуманный пример.
Помни что Server Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity - Не для домашней работы CS/301. ( FAQ)

Если это реальная проблема реального мира, то я приношу свои извинения - вы можете быть 1 из 10000, которые действительно столкнулись с этим угловым случаем в производственной среде.