В ydb используется google tcmalloc, well, он примерно двухлетней давности.
Недавно один коллега обратил на это внимание, попробовал обновить и посмотреть на разных бенчмарках, что получится.
Memory usage упал в tcp-c упал аж на 15%, но латенси стало похуже.

Меня заинтересовало, что метрика того сколько занимают tcmalloc кеши изменилась довольно значительно, не только по размеру (как раз те 15%) но и по форме (став меняться динамически).

Я довольно давно не следил за tcmalloc репой (примерно с тех времён как они рассказывали как сделали большие аллокации huge page aware, 21~ год).
Ну и думал придется покопаться в их коммитах чтобы найти что такого в кешах они поменяли.

Но в процессе поиска наткнулся на то что недавно, они написали статью как меняли tcmalloc на скейле гугла последние два года.

https://zzhou612.com/publication/2024-asplos-malloc/2024-asplos-malloc.pdf

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

Но если приводить TLDR, то
1) Взяли больших потребителей внутри гугла (spanner, f1, bigtable, etc) и пару внешних отличающихся workload-ов (redis, tensor flow, etc)
2) Начали все это активно и по разному мерять (a/b тесты, continues profiling, etc)
3) На каждом уровне кеширования нашли определеные проблемы
4) Получили средний профит на своих ворклоадах уровне: 3.5% по памяти, 1.5% по пропускной способности
5) Ещё интересно что как и с большинством идей из tcmalloc многие из этих можно переиспользовать в других аллокаторах

Ещё наверное интересно, что это показывает в какой-то степени насколько general-purpose аллокаторы (jemalloc, tcmalloc-и, может быть mimalloc) сложно сделать лучше чем сейчас.
Не потому что нельзя под конкретный ворклоад написать аллокатор быстрее в 2 раза, а потому что это замедлит другие юзкейсы.

Резюмируя кажется то что я искал, они называют "Heterogeneous per-CPU cache"
собственно включение которого у нас нет https://github.com/google/tcmalloc/commit/2407bb02b75ba00fd066bd5730a42cd319c303b0
сам код
https://github.com/google/tcmalloc/commit/691f9f62affb27764db8ca26f27159172c439001

Даже Путину можно про порно, а те, кто наставил каках в https://www.tgoop.com/itpgchannel/2510 - ханжи и снобы!

https://www.opennet.ru/opennews/art.shtml?num=62441

29 новых уязвимостей в #gstreamer.

Текст про описание подхода - https://github.blog/security/vulnerability-research/uncovering-gstreamer-secrets/

TL;DR - был использован fuzzer, отдельный интерес представляет то, как коллега строил корпус для фаззинга.

Полагаю, что это только начало, потому что он нашел ошибки только в тех контейнерах, которые он явно таргетировал, а таргетировал он далеко не все, что бывает (mkv/mp4).

https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

TL;DR - из libcurl удаляют альтернативный HTTP/1 backend, основанный на https://hyper.rs/ (кстати, не открывается у меня без VPN, наверное, очередная контора пидорасов! Нет, просто они не осилили QUIC)

Почему?

Закончились деньги из гранта.

Оказалось, что никому не нужно, за 4 года не нашлось ни пользователей, ни разработчиков.

Как-то обсуждали, что fish shell перепишут на Rust - https://www.tgoop.com/it_pg_talks/20668

И, пожалуйста, переписали - https://github.com/fish-shell/fish-shell/releases/tag/4.0b1 (ну, не все, но большую часть, ладно).

Но зато закрыли тикет про то, что в fish shell не хватает set -e, то есть, выхода, когда какая-то команда завершилась с ошибкой - https://github.com/fish-shell/fish-shell/issues/510

Как без этого можно вообще писать серьезные скрипты, я не знаю.

Но точно знаю, что "переписывать на Rust" явно больше fun, чем пилить какие-то продуктовые фичи.

https://www.phoronix.com/news/Linux-6.12-Liquorix-Performance

Заметка от Миши с фороникса, про то, что не надо использовать васянские сборки ядра Linux, потому что получается плохо.

"On a geo mean basis across all of the benchmarks, the upstream kernel ended up being faster by 21%"

https://openbenchmarking.org/result/2412205-PTS-LIQUORIX70&sgm=1&swl=1 - вот тут вот особенно хорошо видно, что Liquorix иногда выигрывает на копеечку, но регулярно сливает в разы, на определенных нагрузках.

https://lwn.net/SubscriberLink/1002371/0ff2be6a2c7624ca/

"Process creation in io_uring"

Пишут про добавление clone() в #io_uring.

Я, даже не читая текст, закатил глаза, и подумал "#ebpf", потому что это очень разумно - загрузить через io_uring программу, которая сделает необходимый setup, и позовет clone()

(вообще, напомню в данном контексте свой текст от 21 года - https://www.tgoop.com/itpgchannel/56)

И, пожалуйста, первый же комментарий про это - https://lwn.net/Articles/1003051/

Но, в целом, этот текст (и дикуссия по ссылкам) не дает ответа на самый главный вопрос - а какая семантика у асинхронного clone()?

Тут же основная проблема - а что происходит, если clone() реально происходит хз когда, когда программа имеет неизвестное состояние блокировок/открытых fd/memory maps и так далее?

Синхронно-то сложно обеспечить нормальное окружение для clone(), а асинхронно - это какой-то леденящий душу пиздец!