В прошлом посте с подавляющим лидерством победило мнение, что безопасность в виде init_on_alloc + init_on_free в ядре не нужна.
А теперь вопрос: сколько из этих 20 людей пошли и отключили её?:)
У меня уже было выключено много где, хакеры, фас!
Обратил внимание на очень интересный доклад от крупной компании на 4 буквы про их опыт с планировщиками нагрузки.
Для начала забавность - ноги растут от шедулера, который для SteamDeck делали вальвовцы - scx_lavd. Да, шедулер "для игр" приживается в промышленном мире серверов :)
Идеи лежат правильные:
- задержки доступа между ядрами процессора весьма ощутимы, есть смысл реже мигрировать нагрузку между ними, да и чтобы горячие L1-L2 кеши больше помогали
- есть смысл использовать в моменте как можно меньше ядер, чтобы минимизировать потребление и тепловыделение
- уменьшив потребление, мы можем больше питания/тепла задействовать на активные ядра
- и тут (барабанная дробь) - по факту у нас уже давно любой многоядерный процессор с "одинаковыми" ядрами содержит весьма разные по свойствам ядра:
- Всегда есть более экономное ядро, но которое не возьмёт максимальную частоту
- и наоборот - есть максимально прожорливое ядро, которое может взять те самые 5+ГГЦ частоты, но оно одно на весь чип
- и это мы даже не начали говорить про процы с топологиями аля big+little, речь про рядовые "ryzen/epyc" процы с "честными" ядрами
- и даже не продолжили говорить про NUMA топологии (которые нынче даже в рамках одного чиплетного процессора присутствуют!)
Т.е. шедулер будущего должен хорошо знать топологию ядер и их свойства, а также мыслить как задержками от решедулинга нагрузки, так и потреблением железа (хотя с потреблением пока есть куда крутить).
Я решил попробовать scx_lavd на своём ноутбуке с Debian testing и ядром 6.17. Настроен был более позитивно, чем оказалось на самом деле, в итоге эффект от "ничего не изменилось на уровне погрешности" до лагов звука из браузера при каких-то расчётах на все ядра аля слайсера 3d моделей. Важный момент - я тестировал кейс "от сети", когда нет надобности экономить потребление. В поездках потестирую ещё работу от батареи, там ожидаю больший эффект на её длительности жизни. В остальном - пока дефолтный шедулер EEVDF из свежих ядер стал от
Про экспериметны с шедулером поговорили, сегодня очередь page-cache'а, но кратко.
Экспериментальный проект (да-да, через ebpf) по манипуляциям с политиками вытеснения кеша в Linux, статья вот. А узнал про это из русскоязычного доклада с OS Dev Conf.
Сам код проекта не факт что будет жить у кого-то в проде, но лёгкая возможность поэкспериментировать с таким - прям отлично.
Отдельно понравилось, сколько LoC ушло на каждую политику (до 600).
Хорошее чтиво на выходные. Жаль ARC опять только упомянули.
Вообще, Page Cache в ядре весьма монолитен, мечта - его лёгкая замена. Мечта ли?
Делюсь методом, как получить все записи докладов с последнего хайлоада бесплатно, а заодно повлиять на качество и актуальность будущих конференций своим мнением. Дерзайте, обратная связь всегда важна!
На нём были классные доклады и про сети, и про оптимизации работы с памятью, и про стораджи 🤗 И даже воркшопы аля "Сделай свой первый патч в крупную БД".
Присоединяйтесь к исследованию отрасли!
Друзья, мы хотим глубже изучить состояние индустрии и понять, что действительно важно для разработчиков высоконагруженных систем.
Для этого нам важно услышать именно ваш опыт:
✔️какие управленческие задачи сейчас в фокусе вашего внимания;
✔️с какими профессиональными вызовами вы сталкиваетесь при выстраивании процессов и работе с командой;
✔️каких тематических блоков или форматов вам недостает на профильных мероприятиях.
Чтобы собрать репрезентативные данные, мы разработали краткий опрос. Его заполнение займет не более 3 минут.
Ваши ответы:
✔️станут ключевым источником данных для масштабного исследования сообщества highload-разработчиков;
✔️помогут нам сформировать максимально релевантную программу конференции HighLoad++ 2026;
✔️позволят выявить актуальные тренды и болевые точки в разработке высоконагруженных систем.
По завершении исследования мы опубликуем его результаты — вы сможете увидеть, как ваш вклад повлиял на общую картину.
🎁 В знак благодарности за участие в исследовании мы предоставим вам доступ к полному архиву видеозаписей конференции HighLoad++ 2025.
✅ Пройти опрос по ссылке
На скринах очередные (1) истории (2) об LLMках от Jens Axboe - maintainer of the Linux block IO. В основном про репродьюс и фикс багов.
И в таком кейсе они могут быть весьма удобны, т.к. модель за много циклов может проделать множество ручной работы. На моих опытах даже задушенный qwen3-coder до 16ГБ может весьма не плохо поразбираться (конечно, более жирные модели шанс успеха сильно повышают).
Главное, к чему пришёл - что для таких игрищ стоит поднять VMку и прокинуть в неё IDE с моделькой, тот же VS Code умеет через SSH работать. А то я видел уже команды rm, которые система считала "безопасными" для выполнения :) Ну и иметь какую-то обратную связь для модельки по типу тестов.
Какой моделью пользуетесь, какой основной сценарий (автодополнение/чат/агентская работа)?
https://news.ycombinator.com/item?id=47258500
Очередной тредик про bitflips, как всегда:
The common causes we discovered for the problem were:
- overclocked CPU
- bad memory wait-state configuration
- underpowered power supply
- overheating due to under-specced cooling fans or dusty intakes
Картина маслом: LLM бот увидел bounty за баг, и решил подзаработать, а чтобы не упустить шанс - стал каждый час требовать репродьюс. Жаль, что на этом всё и закончилось.
И следом - ещё очень похожие по эксплуатации local privilege escalation уязвимости с заражением pagecache https://github.com/V4bel/dirtyfrag , только в этот раз что-то пошло не так и фиксов ни в одном дистре ещё нет.
tl;dr: sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
О времена, о нравы, нынче поменять язык - дело наличия нормальных тестов. А что говорить о смене лицензии тем же образом... Но это отдельный холивар.
1млн+ строк диффа, даже если это немного фиктивная статистика - мощь.
10 июня проведём уже 4й InfraDev Meetup, в этот раз про AI в SDLC инфровой разработки, распределённое обучение LLM, и про более вечное тоже не забудем - проблематика имаджей ОС в облаках.
Мск, очно, 10 июня, ламповый зал на ограниченное количество мест, где можно и нужно челленджить спикера прямо с мест, приходите или слушайте онлайн! Увидимся!
Трудно было не заметить (за собой и окружающими) что во всех каналах/конференциях/чатах, даже если они посвящены узким темам (а я сижу во всяких там iaas/storage/sdn и тд обществах), всё равно бОльшая часть контента и обсуждений сейчас - про ИИ. Тут ещё и MythosFable подъехал. Вот и получается, что основные темы площадок смещаются. Плохо ли это, если надеть шапочку организаторов таких обществ/конференций?
Думаю, что мы в очень интересном моменте живём - слом парадигм и появление чего-то по настоящему нового. Да, в моменте оно ещё не устоялось и мы много говорим про опыт "на сейчас". Но пережить это интересно. И рассказывать про это тоже нужно.
Вот и на Saint HighLoad++ практическая секция про ИИ В SDLC (ЖЦР не звучит :() сильно выросла в отдельное большое направление. Про классические для площадки темы тоже не забыли.
Питер, 22-23 июня https://highload.ru/spb/2026. Тоже буду там, пересечёмся!
Был приятно удивлён обнаружить на кинопоиске первые серии нового Призрака в доспехах (2026)! Эта версия максимально близка по духу к оригинальной манге, она точно будет менее серьёзной чем фильм 1995го и оба сезона GITS SAC, и мне нравится что они отличаются. По саундтреку даже чем-то на Cowboy Bebop похоже, кайф!
Когда первый раз смотришь на описание mmap для доступа к диску, то всё выглядит так потрясно - ядро всё за тебя сделает, виртуальная память вжух-вжух, не надо следить что тебе нужно и просто знай себе да читай-пиши с нужным смещением. Как хорошо всё начинается!
А потом - бац, оказывается неявное поведение "простого доступа по смещениям" начинает сильно стрелять именно своей простотой (за счёт сложности жизни ядра, да)... По факту гранулярно и просто контроллировать доступ к диску становится очень сложно. Особенно феерично оно стреляет на записи. И почему-то многие пытаются его использовать для записи append-only... Вот очередная история с journald, где только после подробной иллюстрации и "срача" на hn за многие коды авторы решили что-то подумать о диком write-amplification.
Нет ничего лучше явного и простого, блин. Вот вам классная и весёлая преза в тему.