Плохо документированные особенности Linux

По поводу mmap есть нюанс:

       M_MMAP_THRESHOLD
              For allocations greater than or equal to the limit specified
              (in bytes) by M_MMAP_THRESHOLD that can't be satisfied from
              the free list, the memory-allocation functions employ mmap(2)
              instead of increasing the program break using sbrk(2).

Причём сама glibc решает, когда mmap-ить, а когда не следует.

Когда-то я уже устраивал спор на тему, поэтому напишу и сюда. Если программа выделяет 128МБ (~много МБ) памяти, будет ли при этом выделено много страниц по 4кБ, или не так много страниц по 4МБ? И почему?

Только не mks, а µs или на самый крайний случай us.

Спасибо за список литературы, заказал себе пару книг!

> Задержанные TCP пакеты
вот очень бы хотелось услышать решение таких проблем…

В последнем абзаце речь о «Posix Threads»?
А то, не очень ясно.

А на русском про ядерное программирование Линукса что-нибудь выходило?

Поскольку никакой информации так и не нашел, пришлось мерить руками. Оказалось, на моей системе (3.13.0) — всего 120 байт

Это, мягко говоря, сомнительно, потому что единица выделения с помощью mmap — 1 страница, что сильно больше 120 байт

Позвольте мне указать на некоторые неточности в статье, которые также повторяются в комментариях.

Выделение памяти. free() действительно возвращает память в систему, но не во всех случаях, и уж тем более про это можно забыть если память сильно фрагментирована. Более подробно (с нужными ссылками на документацию) это описано здесь: Linux: Native Memory Fragmentation and Process Size Growth

Unlike certain Java garbage collectors, glibc malloc does not have a feature of heap compaction. Glibc malloc does have a feature of trimming (M_TRIM_THRESHOLD); however, this only occurs with contiguous free space at the top of a heap, which is unlikely when a heap is fragmented.

Если есть проблемы с памятью, то лучше переключиться на другие аллокаторы, например, jemalloc — он используется в Mozilla, Facebook, во многих высокопроизводительных и встроенных системах.

clone (системный вызов sys_clone). К сожалению, здесь очень много неточностей:

• fork() не является подобием clone(), это обертка над ним (man 2 fork: Since version 2.3.3, rather than invoking the kernel's fork() system call, the glibc fork() wrapper that is provided as part of the NPTL threading implementation invokes clone(2) with flags that provide the same effect as the traditional system call.)
• clone() не делает адресное пространство общим, это все конфигурируется опциями (man 2 clone: If CLONE_VM is not set, the child process runs in a separate copy of the memory space of the calling process at the time of clone().)
• Это не упоминается в статье, но был вопрос в комментариях: pthread использует clone (man 7 pthreads: Both threading implementations employ the Linux clone(2) system call.) Но в общем случае для реализации многопоточности хватит и прямого использования clone (Minimalistic Linux threading)

В целом документация есть на все, но это надо знать где смотреть. Опыт работы над встроенными системами научил меня всегда смотреть на документацию API, даже такую элементарную как malloc()/free(). Вот, например, из документации fclose (казалось бы, какие тут могут быть сюрпризы, по крайней мере, с позиции Junior/Intermediate разработчика): Note that fclose() only flushes the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).

Для меня самым неприятным сюрпризом за время моей работы с Линуксом стало то, что я не могу сказать, сколько памяти доступно в системе для выделения. free (и шаманство вокруг /proc/meminfo) даёт апроксимацию первого порядка, но понять, «где память», или «будет OOM после выделения ещё 100Мб памяти или нет» невозможно.

В лабораторных условиях можно. В продакшене (с всякими обширными shmem, tmpfs и т.д.) — нет, потому что часть памяти в cached оказывается невытесняемой.

Очень вредная статья. Устаревшая информация приправленная домыслами и догадками.

По существу, к прокомментировавшим выше, могу добавить, что флаг TCP_QUICKACK придуман совсем для другого, а именно: задержать отсылку ACK'a если знаем, что потом будем слать данные. По сути убрать отправку пустого пакета с флагом ACK если уверены, что так нужно. К примеру, после тройного рукопожатия в http сессии мы знаем, что пошлём данные от клиента, так что можем придержать последний ACK и отправить его с телом запроса. А у вас скорее всего был включён net.ipv4.tcp_slow_start_after_idle.

По поводу документации и недокументированности не согласен. Документация в манах и в списках рассылки. Код написан довольно понятно. Вы видели лучше документированные системы которые активно разрабатываются?

З.Ы. Вот хорошая книга про внутренности сетевого стека Linux (местами гик порн): www.amazon.com/TCP-Architecture-Design-Implementation-Linux/dp/0470147733

So low

Про потоки и дескрипторы — не верю.

Проверка:

int main()
{
    int fd = ::open("/dev/zero", O_RDONLY);
    char buf[2];
    cout << ::read(fd, buf, 2) << endl;
    std::thread([&]() { ::close(fd); }).join();
    cout << ::read(fd, buf, 2) << endl;
    return 0;
}

Выводит:

2
-1

Т.е. дескриптор текущего потока, закрытый в другом потоке, закрыт и в текущем.

del

Товарищи amosk encyclopedist izyk degs
Огромная просьба от меня и других, кто следит за комментариями к этой статье, — опубликуйте результаты просветления про потоки и дескрипторы в виде отдельной статьи (если просветление всё-таки наступит и все с ним согласятся).