H2o: зачем нам MAP_SHARED для h2o_buffer_reserve ()

есть ли другие процессы, которые будут к нему обращаться? если нет, почему бы не установить MAP_PRIVATE

Цель использования mktemps + fallocate + mmap - создать буфер с файловой поддержкой, чтобы максимальный объем пространства, который можно использовать для буферизации данных, был ограничен _свободным пространством на диске вместо swap_. MAP_PRIVATE противоречит этой цели.

кроме того, можем ли мы использовать mremap (2) вместо mmap (2) и munmap (2) на платформе, которая поддерживает mremap?

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

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

buffering large amount of data is a secondary strategy вот в чем дело.
думаю, программа редко попадает в mktemps + fallocate + mmap .

потоковый запрос обрабатывается обработчиком, которому не нужны большие буферы, верно?

На мой взгляд, использование общего или частного ресурса mmap (даже в качестве временного заполнителя для загрузки) - плохая идея. Расположение $ TMP или $ TMPDIR может быть любым в пользовательской среде, например, жестким диском ... это просто дополнительный шаг, который следует запомнить администратору. Не говоря уже о том, что одновременная загрузка больших файлов легко создаст нехватку памяти, если $ TMP монтируется на ramdisk.

Мне очень нравится ваше предложение и указания по обеспечению работы потокового запроса с обработчиками, не являющимися прокси. Ждем и готовы к испытаниям!