Управление памятью в сетевой подсистеме и ядре FreeBSD в целом

[nuclight]

Эта статья будет полезна системным администраторам и программистам, работающим в ядре FreeBSD. Осмыслив изложенное здесь, можно понять, почему же бывает паника по kmem, что такое состояние keglim/zoneli, как читать непонятные циферки в выводе vmstat -m / vmstat -z, и что же такое эти самые mbuf и nmbclusters. Программистам, приступающим к работе не

Comments

[sir_dog]

Благодарю!

[nobody_source]

Хорошо, спасибо, в BSDmag тоже вышла статья про память.

[ext_1023243]

Если кому интересны подробности архитектуры, советую почитать книгу "Архитектура операционной системы UNIX" Мориса Дж. Баха. Там подробно изложены все особенности построения юникс-подобных ОС.

Статья отличная. Благодарности автору.

[boorick]

очень интересно. Спасибо. Сохранил на диск.

[ext_1027625]

Из Epilogue к TCP/IP Illustrated Volume 2:
The Berkeley networking code was designed on VAXes when a VAX-11/780 with 4 megabytes of memory was a big system. For that reason some of design features (e.g., mbufs) emphasized memory savings over high performance. This would change if the code were rewritten from scratch today.
Stevens 1993 год.

Интерасно как бы код сетевой подсистемы выглядел если бы был переписан сейчас.

[nuclight]

Скорее всего, это была бы структура, аналогичная линуксовому sk_buff, но несущая в себе, кроме области данных, заголовки для как бы трех mbuf, одного "кластера" (себя) и m_pkthdr. То есть, имелись бы указатели на две _внешние_ области данных *head и *tail, для большинства пакетов неиспользуемые (весь пакет непрерывен в самой этой структуре), но снимающие ограничения на лимит места в sk_buff (и необходимость его там резервировать), для случаев, например, туннелирования - в этом случае был бы оптимизированный "связный список" из 2-3 областей данных, код манипулирования которым более простой сравнительно с mbuf за счет того, что областей точно не более трех.