ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Vadim Goncharov                      2:5020/400     14 Sep 2005  22:14:08
 To : Andrey Simonenko
 Subject : malloc() overcommit bug
 -------------------------------------------------------------------------------- 
 

 >> AS> Это известное свойство.  Если сделать гарантию доступности памяти
 >> AS> (phys + swap) для процессов, то тогда не возможно сделать приватный
 >> AS> mmap() для файла в 1G и промодифицировать только одну страницу в
 >> AS> этом файле на системах, где нет достаточно памяти (phys + swap).
 >> AS> Аналогично не будут работать программы где выделяется много памяти
 >> AS> (например через mmap() /dev/zero), а используется несколько страниц.
 >> AS> Hапример rpc.statd 256M/1M, think (www.find-a-drug.org) 208N/5M
 >> AS> (xxx/yyy, xxx -- виртуальный размер, yyy -- используемая память).
 >> Так они же через mmap() выделяют, а не через malloc(), в чем
 >> проблема?
 AS> Hет разницы, в терминологии FreeBSD если необходимо выделить
 AS> кусок памчяти, то для него создаётся vm_object или расширяется
 AS> существующий рядом стоящий.  Этот vm_object является владельцем
 AS> страниц виртуальной памяти vm_page.  Эти vm_page выделяются
 AS> как только есть промах по странице.  Так называемое ленивое
 AS> выделение.  В случае приватного выделения памяти в mmap() на
 AS> /dev/zero или файл, аналогично выделяется vm_object но теперь он
 AS> теневой, и как только будут промахи по записи теневой объект
 AS> станев владельцем приватно промодифицированной страницы.
 AS> Иными словами ОС не знает что намерен сделать процесс вызвавшый
 AS> mmap() для приватного отображения файла в память.  Будет
 AS> ли он модифицировать одну траницу или весь N Гбайтный файл.
 
 Тот, кто мне про это сказал, пробовал и malloc() c забиваниме нулями
 включением соответсвующих malloc_options. Результат такой же.
 
 AS> malloc() в FreeBSD реализован через sbrk().  Hо возможно его
 AS> (боле эффективно) можно реализовать через mmap() или схожий
 AS> интерфейс. В OpenBSD что-то сделали по рандомизации выделения
 AS> адресов через malloc() и гарантию выделения разных адресов.
 AS> Я не успел посмотреть в sys/*, но подозреваю, что они используют
 AS> отдельный системный вызов, в ядре это реализуется просто.
 AS> Я видел описание и обсуждение на www.kerneltrap.org.
 
 B sbrk(2) сказано, что это legacy interface.
 
 >> AS> Теоретически можно сделать гарантию памяти только нескольким
 >> AS> процессам, чтобы они всегда имели достаточно памяти как swap'е,
 >> AS> но эти процессы должны иметь предсказуемые характеристики по
 >> AS> использованию памяти, иначе если подобный процесс будет делать
 >> AS> в процессе своей работы что-то вроде приватного mmap() или sbrk()
 >> AS> для больших объёмов, то будут выкидываться все остальные процессы.
 >> AS> По теме:
 >> AS> * Solaris kernel internals, раздел про VM.
 >> AS> * Таненбаум, не уверен, но что-то должно быть в моделях виртуальной
 >> AS>   памяти.
 >> AS> * Письмо (месяц назад) в freebsd-hackers с патчем на эту тему.
 >> Хм, я не настолько в теме, а больше из advocacy / познавательных
 >> целей :)
 AS> В этом Solaris kernel internals (доступно как PDF в P2P и наверное
 AS> где-то WWW) про это рассказывается.  Если мне не изменяет память,
 AS> то PhD Cranor'а про UVM также обсуждает эту проблему (ссылку
 AS> см. на www.netbsd.org в разделе документации).
 
 Так эта проблема общая для всех *BSD ?
 
 AS> Hапример стек растёт в FreeBSD/i386 по 32 Кбайт, т.е. по 8 страниц,
 AS> даже если требуется всего одна страница.  А в случае полного
 AS> резервирования потребуется резервировать все 8 страниц, в случае
 AS> ленивого выделения потребуется одна страница.
 AS> Скорее всего есть подводные камни при реализации этого алгоритма
 AS> и скорее всего где-то будет dead-lock в ядре.  Здесь надо очень
 AS> хорошо полнимать скорее implementation чем design. 
 
 Hу ведь можно сделать его отключаемым, как в линуксе?
 
 >> AS> Или речь идёт про что-то другое?
 >> Возможно, про другое. Человек, который мне это сегодня в irc сказал,
 >> вообще приверженец BSD, но как-то раз у него из-за этого навернулась
 >> программа, считавшая "на стенде" 2 недели, ему было очень обидно, и
 >> он теперь для такого использует линукс, в котором переключатель есть.
 >> Т.е. претензия в том, что malloc() вернул не NULL, а раз вернул,
 >> значит программа по ANSI C вправе эту память использовать, а ядро ее потом
 >> нечестно убивает.
 AS> Более нечестно прибивается процесс, когда совсем нет памяти и
 AS> этот процесс, которого прибивают, даже не виноват в этом.
 AS> См. комментарий в sys/vm/vm_pageout.c перед вторым вхождением
 AS> слова bigproc ("If we are critically low...").  Так же см.
 AS> многолетнее обсуждение по этому поводу в freebsd-hackers.
 
 Да, я такое наблюдал, когда пробовал пускать fork-бомбу с malloc().
 
 -- 
 WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
 [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
 --- slrn/0.9.8.1 on FreeBSD 4.11/i386
  * Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор