Что может блокировать создание тредов выше 12000 если все лимиты задраны по максимуму?

Эм, а зачем тебе свыше 12000 тредов в одной программе?)

Здравый смысл, не?

Какие хоть лимиты-то задраны расскажи, откуда знать может ты там задрал нерелевантное и даже не погуглил.

1. Проверяй что стек реально 256к, выглядит так, как будто ты упираешься в лимит адресного пространства: 32 000 000 000 / 12 000 = 2.5 метра, если у тебя стек 2 метра, а остальное - другие процессы - то реально уперся.
2. проверяй количество пидов, может в них попячился.
3. смотри исходники pthread_create, они доступны, это тебе не черный ящик с шиндой.

В kernel/fork.c посмотри все EAGAIN и проверь, что на них не наступаешь.

Ещё можно тупо systemtap натравить, чтобы он call graph напечатал: https://www.sourceware.org/systemtap/examples/#general/para-callgraph.stp Мне когда неохота в незнакомой части ядра ковыряться, я им быстренько нахожу.

Эм, а зачем тебе свыше 12000 тредов в одной программе?)

В EMCшную бытность один древний кусок кода работал на проприетарной юниксоподобной операционке без юзерспейса (только кернель мод) на древних интеловских процах, где глубоких оптимизаций в пайплайне ещё не было, так что контекст свич с одного кернельного треда на другой был весьма дёшев. Они использовали треды, как зелёные. Потом наступил 2013, новые интелы, код тот в юзерспейсе в линуксе заработал, нагрузки решили отмасштабировать увеличением кол-ва тредов, в итоге тредов стало где-то тыщ 16, ЕМНИП.

Десятки патчей на ядро накладывали, чтобы это шевелилось, там даже у шедулера проблемы были их в адекватное время перебирать.

А ещё в юзерспейсе можно было preemption запретить, установив один лишь бит в памяти, ибо код не был к preemptive модели готов, а кернельщики были лучше, чем товарищи, тот код написавший.

Ну требуется запустить г-но мамонта «как есть». Переписывать будем когда то в будущем.

Отредактировал исходное сообщение

Уже пользовался — не достаточно

Поди с солярки перенесли на линукс? :)

на фряхе пробовал?

Вобщем, установили чистую убунту, применили настройки описанные в начале треда и на этом 20к удачно проскочили. Сейчас застряли на 28к, но по какой-то другой причине.

нет, у меня с фряхой не сложились отношения.

Pthreads транслирует системное ENOMEM в EAGAIN. В остальном говорить что-то конкретное не получится без инфы о фактических показателях системы под нагрузкой.

Pthread_create это не системный вызов. Запустить под strace -f -e trace=clone,mmap, чтобы понять, какой системный вызов фейлит. Это либо mmap, которым стек для потока выделяется в адресном пространстве процесса, либо clone, которым lwp создаётся.