кстати, тоже самое с r&d отделами в корпорациях, будьте осторожны

С Новым Годом!

Для многих людей первое сентября первый учебный день в году – это что-то далекое, оставшееся в универе (или даже в школе). Поэтому для них вся эта сентябрьская суета становится неожиданным, иногда мешающим событием: утром появляются внезапные пробки на дорогах, общественный транспорт тоже забивается до отказа, по соседству селятся новые шумные квартиранты и т.д. Понятно, что все меняется, когда дети этих людей идут в школу (тут то они и вспоминают про 1 сентября), но до этого же еще дожить надо.

У меня же первое сентября всегда было связано с началом семестра, т.к. преподавание и собственное обучение в универе у меня пересеклись по старшим курсам. Поэтому для меня это абсолютно естественный и правильный старт года, куда более логичный и радостный, чем, например, 1 января.

—

Но однажды я таки забыл про начало семестра. Это было в год, когда мы начали активно проводить митапы JUGNsk и пытались найти себе спонсоров на ближайший ивент. Стоит понимать контекст: мы были внезапно появившимися независимыми игроками, проводящими Java митапы в Нск, при том у нас отлично получалось! Собирали полные залы, зазывали классных спикеров. Не сказать, что большим компаниям это нравилось или что они все спешили нам помочь, скорее с ними приходилось конкурировать. Так что деньги нам были очень нужны.

И вот, назначили мы, значит, встречу с директором одной уважаемой IT компании (точнее местного ее филиала). Я надел пиджак (!!!), а возможно даже и брюки, и весь такой серьезный пошел на деловую встречу, с четким намерением объяснить человеку, что ему просто жизненно необходимо дать нам много денег на шашлычки и бейджики на наш следующий митап, да и вообще.

Питчил я яростно, прям как Джордан Беллфорт из волка с Уолл-стрит, необходимость поддержки местного Java комьюнити становилась все более очевидна всем в кабинете, казалось, что шашлычки на кучу ближайших митапов уже у нас в кармане, но тут... у меня звонит телефон, и в трубке удивленный голос старосты спрашивает: "Иван, а у нас пара то по С++ будет сегодня"?

Да, это было 1 сентября. Лицо мое явно приняло такое потерянное и скучное выражение, что питчинг на этом и кончился. Денег нам, конечно же, не дали. Вместо этого рассказали какую-то притчу из директорской жизни, пообещали быть на связи и мягко, но уверенно выпроводили восвояси.

—

С тех пор я понял, что особое отношение к первому сентября – это супер сила, которой не стоит пренебрегать. Ну, и с пиджаками у меня с тех пор как-то не заладилось.

Так что всех с праздником, начинаем прекрасный новый учебный год! В этот раз аж с тремя поколениями наших студентов одновременно.

Я начинаю думать, что вообще все корпорации приблизительно одинаковые. Еще один все понял, да.

А что там со стартапами? Наоборот: все разные?

Made at Intel

В этот раз взял в самолет книгу Валерия Черепенникова «Made at Intel» про его 22-летний опыт работы в корпорации Intel. Я ее даже дважды купил для этого: заказал на Озоне, а когда понял, что она не успевает прийти до командировки, купил еще и электронную на литресе. В результате так ее и прочитал с телефона.

Я так понял, что ее главы выходили на Хабре во время написания, но я из них читал только одну из последних: о противостоянии YADRO и Huawei в Нижнем, когда они боролись за интеловских инженеров после ухода конторы из РФ в 2022 (и вы бы знали, как я тогда эту статью прочувствовал, ведь все описанные там проблемы найма новых людей в Ху мне хорошо знакомы). Теперь я ее что-то даже на хабре найти не могу, поэтому оставляю ссылку на пост в tg канале автора.

Дальше немного про книгу ↓

Вообще, в своей жизни я часто сталкиваюсь с бывшими интеловцами, но почти всегда по касательной. Я все-таки сильно младше поколения Новосибирских (или Питерских) инженеров, которые успели там основательно поработать и на формирование которых Интел смог повлиять. (А с нижегородцами впервые познакомился только прошлом летом, уже на внутреннем хуавейном мероприятии). Мои сверстники в лучшем случаи успели побыть там интернами, а те бывшие интеловцы, что старше, всегда казались мне носителями какой-то инородной, непонятной мне культуры.

Так что в «Made in Intel» я надеялся найти какие-то ответы и объяснения. Книга интересная и хорошо написанная, всем советую. Но у меня она вызвала какие-то смешанные чувства:

– С одной стороны, очевидно в Интеле работали потрясающие талантливые инженеры, предлагавшие уникальные технологические решения (да один Бабаян чего стоит!). Не то, чтобы это была новость для меня, тот же Шипилев ведь вышел из Интела, но многие главы книги - дополнительно, яркое и наглядное тому подтверждение.

– С другой стороны, фактически каждая глава показывает, как люди сталкивались с корпоративными играми (глава про доносы в компании оставила прям неизгладимое впечатление), главенством менеджеров и сейлсов, нелогичными (религиозными) решениями в плане технологий, кровавыми сокращениями, Бюрократией с большой буквы Б и т.д.

– При этом часто звучит (что в книге, что в жизни от бывших интеловцев) тезис о некой особой корпоративной культуре, о комфортности компании (пусть и на фоне застоя). Ну и вообще, чувствуется теплота в повествовании. Mother Intel и вот все. Вполне допускаю, что я не уловил иронии, но это вызывает у меня сильный диссонанс. Вот вся эта жесть - это и есть интеловская корпоративная культура, да? Или корпоративная культура в том, что там при всем при этом там классные инженеры? Но они ведь много где классные, непонятно.

Но в любом случае, для меня книга оказалась полезной по двум причинам:

– Мой недавний тезис про «все корпорации одинаковые» я теперь сам подвергаю сомнению. Я бы скорректировал его так: «во всех корпорациях есть системные проблемы, иногда они совпадают, а иногда - сильно отличаются». Например, по книге мне очень понравилось, что Intel - именно интернациональная компания, судя по всему, там действительно сплав культур (Ху - это, конечно, компания с чисто китайской культурой, остальные должны подстраиваться). Но к RnD, например, у нас явно относятся намного лучше, это и сам Черепенников подтверждает в книге, он же теперь из красных. Но и там и там абсолютно похожие истории про противостояние человека и бюрократической системы, в которой первый обычно проигрывает. Это, конечно, плохо для меня, т.к. я с системами не уживаюсь: мне вечно нужно что-то странное, гибкое, непривычное.

– Кроме того, иронично, но именно в этой поездке я сталкивался с приличным количеством бывших интеловцев, которые нет-нет, да апеллировали к своему прошлому опыту в корпорации. Кое-кто даже с гордостью говорил, что строит в своей команде интеловскую корпоративную культуру. Наверное, я чуть лучше стал понимать, о чем они говорят. Не уверен, правда, что это понимание пошло нашему общению в плюс.

Как-то так! Было бы очень интересно когда-нибудь прочитать «Made at Huawei» от того же автора, уверен, там у него уже тоже много корпоративных историй. У меня, кстати, тоже, но я пока не решаюсь их публиковать, коплю)

#ваня_читает

Знающие люди говорят, что интеловская корпоративная культура заключается вот в этом!

Ну, вот такого в книге не было, да.

В отсутствии процессов ради процессов, в грамотном Code of Conduct и в инженерной культуре

Все эту неделю я отец-одиночка, вайбы абсолютно такие

Налог на стековую память или glibc виднее

Недавно отлаживали вместе с китайским коллегой забавный баг. Ну, как вместе: воспроизводящее окружение было только у него, поэтому я ему говорил разные свои идеи, а он собственно отлаживал, по пути их подтверждая или опровергая, и присылая новые логи. Очень хороший, кстати, чел, первый китаец, с которым мне было прям комфортно отлаживаться по удаленке. И в конце концов раскопал все именно он.

Баг выглядел страшно: пользователь стартует нашу VM из своего сишного кода, тут же при инициализации рантайма случается SIGSEGV, все разваливается. Ну т.е. с точки зрения клиента у нас просто ничего не работает.

Первичный анализ показывает, что SIGSEGV случается в недрах glibc, а точка входа - это вызов pthread_create из нашего рантайма, с помощью которого мы создаем один из наших утилитарных тредов. Еще несколько битов информации, которые мы быстро получили:

1) если покрутить аналог -Xss (желаемый размер стеков), то развал либо превращается в pthread_create() failed, либо вообще пропадает! И вот последнее сыграло с нами плохую шутку, т.к. менеджмент решил, что крутить стеки в поисках значения, на котором все будет работать - это перспективнее, чем отлаживать исходную проблему (из-за этого это все затянулось на несколько месяцев).

2) SIGSEGV происходит, когда код из glibc записывает что-то ровно в середину стека создаваемого треда. Т.е. кто-то внаглую пишет в наш стек.

—

Тут стоит немного пояснить контекст, чтобы стало понятно, почему я так возмущен.

Само собой, мы в рантайме создаем много тредов, как утилитарных, так и для работы самого приложения, базируются они на OS тредах, поэтому нам нужен pthread_create. Более того, когда вы создаете тред через pthread_create, у вас всегда есть выбор, как работать со стеком рождающегося потока:

1) вы можете довериться дефолтному поведению: ограничение на размер стека будет взято из системы или просто выбрано дефолтное значение в 2mb => сам стек будет саллоцирован где-то и выдан потоку, у него в конце уже будет расписана guard секция (ее размер тоже можно задавать)

2) либо вы можете оказаться ловким и умелым и взять управление стеком на себя. Тогда уже вы сами аллоцируете его где-то в памяти, сами себе расставляете guard pages, потом вызываете pthread_attr_setstack и выставляете треду подготовленную вами область памяти в качестве стека. При этом в документации явно сказано, что это мало кому нужно:

These functions are provided for applications that must ensure that a thread's stack is placed in a particular location. For most applications, this is not necessary, and the use of these functions should be avoided.

Но мы то рантайм пишем, нам КОНЕЧНО нужно контролировать стеки самостоятельно. Одна из важных задач рантайма - реализовывать threading для соответствующего языка, что включает эффективную реализацию стек-чеков, обработку SOE, разработку stackful корутин и так далее. В общем, мы здесь совершенно не можем полагаться на стеки, которые сделает glibc, нужен полный контроль.

И вот представьте: есть специальный API, который позволяет вам этот полный контроль получить. Вы его аккуратно используете, и понимаете, что после этого в ваши стеки кто-то гадит. Не порядок. ↓

#дух_машины

Копаем чуть глубже, обнаруживаем, что glibc решила поаллоцировать на нашем стеке static TLS (т.е. место под объекты thread-local-storage, используемые именно из бинаря, а не загруженных модулей). Довольно подробно все устройство TLS описано вот здесь, при том в последнем параграфе интересное уточнение: "в glibc в случае тредов, создаваемых pthread_create, static TLS рисуется прям на стеке создаваемого треда, так что получается сэкономить на аллокации!".

Это может с натяжкой звучать логично для сценария, когда аллокацией стека занимается сама glibc, но давайте осознаем, что происходит в нашем случае. Мы аллоцируем память под стек своего треда (ориентируемся при этом на заданный -Xss), расписываем там себе защищенные страницы, в общем, готовим все к исполнению.

Потом приходит glibc и говорит: "Хочешь 256Kb стек? Хех, без проблем, но не забудь заплатить налог: нам еще нужно сколько то килобайт, чтобы нарисовать на твоем стеке static TLS". ↓

Налоги - это вообще неприятно, но здесь это буквально вставляет нам палки в колеса. Так уж вышло, что мы рисуем для треда не один стек, а два (стоящих в памяти подряд). В некоторых ситуациях мы экстренно переключаемся на второй (альтернативный) стек, чтобы на нем сделать кое-что важное, потом возвращаемся назад. Соответственно, у каждой из половинок стека есть guard page - защищенная на запись страница, в которую, если что, ударится исполнение, когда стек переполнится.

+------+---------------+-----+----------------------+
  ||||     Alt stack    |||||        Real stack     |
+------+---------------+-----+----------------------+
   ^                      ^   
Guard #2   <= grows   Guard #1       <= grows

И финальный кусочек пазла: как вы помните, в пользовательском сценарии наша VM вызывается (инициализируется) из C кода. Т.е. размер static TLS зависит совсем не от нас, а от того, насколько много писатель сишного кода памяти потратил на __thread переменные. И в зависимости от этого размера начинаются спецэффекты:

1) Если размер больше половины размера нашего стека => мы ткнем в нашу защищенную страницу в серединке стека => SIGSEGV,
2) Если размер TLS больше, чем запрашиваемый размер стека => pthread_create просто обломится,
3) Если размер TLS меньше, чем половина стека => ну, TLS просто сожрет часть основного стека, т.е. SOE случится куда быстрее, чем пользователь мог бы подумать.

Чудесно! ↓

Но неужели мы одни такие умники, кто решил взять управление стеками в свои руки? Конечно же нет! На самом деле за этим потрясающая история, длиною как минимум в 14 лет. Пронаблюдать ее можно вот в этом древнем, но открытом ишуе: https://sourceware.org/bugzilla/show_bug.cgi?id=11787

Краткий пересказ:

На дворе 2010 год.

*вот вы помните, что вы делали в 2010 году? я помню: заканчивал второй курс, матан сдавал последний раз, собирался специализироваться на вычмате*

В багтрекер glibc приходит пользователь (догадываюсь, что из Гугла) и описывает схожую проблему: в хроме создаются треды со стеком 128К. Обычно все нормально, но в профилировочном режиме начинает активно использоваться TLS, поэтому pthread_create перестает работать. Далее диалог мейнтейнера с репортером:

М: да, мы TLS на стеке аллоцируем, все верно. А вы что хотели?

Р: хотели, чтобы когда мы запрашиваем стек 128К, у нас было бы в распоряжении 128К. Вроде логично?

М:

The "stack" is purposely ambiguous and once handed over to the implementation the implementation has complete control and can do what it wishes including use some of it for TLS which is what we do.

В общем, мейнтейнер упрямится: говорит, что нужно обсудить это с представителями основных дистрибутивов, зовет их в тред, все вместе думают. Обсуждение приходит к необходимости эвристики: когда можно TLS на стеке оставлять, а когда все-таки нет. Уже даже патч готов, но его не принимают, т.к. это все еще выглядит, как слишком большое и опасное изменение. Изначальное обсуждение длится уже 2 года.

—

Наступает 2013 год.

*я уже закончил бакалавриат, женился и 2 года, как работаю в Excelsior, а вы?*

В тред возвращается репортер, спрашивет: как там прогресс? А то абсолютно тоже самое случилось с JVM и JNI: если создавать JVM из нативного кода, где много __thread переменных, то Java треды потом не создаются.

Еще в тред приходит разработчик musl и рассказывает, что там проблема решена: они аккуратно оценивают запрошенный размер стека и размер TLS, если TLS больше, чем 1/8 размера памяти, которую выдали под стек, то он аллоцируется отдельно.

Мейнтенер обещает вернутся к этой таске на следующей неделе.

—

Дальше сообщения уже за 2015 год.

*у меня первый год в аспирантуре (я уверен, что защищусь), наконец сдал на права и купил первую свою машину*

Оказывается, что с похожими проблемами сталкиваются рантаймы разных языков: Rust, Java, Ruby, скорее всего и Go. Веры в то, что в glibc это поправят, у них особо нет, поэтому они хачат: зовут приватную функцию __pthread_get_minstack, получают размер static TLS и учитывают его в своих запросах в pthread_create.

Мейнтейнер соглашается, что дело то, похоже, серьезное, так что он точно скоро им займется.

—

2017-2020 годы.

*сколько же тут всего у меня было? Первые доклады, JUGNsk, Колька, переход в Huawei, первый SnowOne*

Уже довольно редкие сообщения от новых репортеров из разных компаний о том, что они столкнулись с проблемой, нашли workaround в коде HS и применили его. Но было бы неплохо починить в glibc. Мейнтейнер согласен и благодарит их за информацию. Это поможет ему приоритезировать этот таск.

—

Последнее сообщение датируется 2022 годом.

*стартуем SysPro, решаю оставаться в РФ на фоне всего происходящего*

Какой-то такой же археолог описывает текущее состояние дел: код порефакторили, но основная логика осталась такой же. В musl все хорошо с их эвристикой. В хроме проблема больше неактуальна (этот кусок кода переписали), но в целом - проблема никуда не делась. Мейнтейнер не отвечает.

—

2024 год, с этим, наконец, столкнулись и мы.

Думаю, нужно ли дописать что-то в тот тред? Прикоснуться к истории еще сильнее? Наверное, ограничусь этим блогпостом, да буду дергать приватную __pthread_get_minstack, чтобы учесть ее в общем размере стека. Получается, что поднимаем цены (реальные запрашиваемые размеры стека), чтобы покрыть налоги от glibc.

—

Вот как бывает: у кого-то половина осознанной жизни прошла, а у кого-то ишуй так статус и не поменял. Ну, что поделать! В конце концов, что такое для системного программирования каких-то 14 лет?

#дух_машины