Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от opennews (??), 12-Фев-26, 16:15
В кодовую базу, на основе которой формируется ядро Linux 7.0, принят набор изменений, при проведении стресс-тестирования в 100-гигабитной сети  позволивших  повысить производительность обработки входящих  UDP-пакетов на 12%. Оптимизация реализована путём ручного инлайнинга 2 функций. Отмечается, что функция timecounter_cyc2time() может вызываться на каждый входящий пакет, поскольку современные протоколы требуют учёта времени поступления пакета. Из-за этого на нагруженном сервере функция timecounter_cyc2time() может вызываться более 100 млн раз в секунду... Подробнее: https://www.opennet.me/opennews/art.shtml?num=64783
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от Аноним (1), 12-Фев-26, 16:15
> такие как FDO (Feedback Directed Optimization), LTO (Link Time Optimization) и PGO (Profile Guided Optimization) А разве PGO и FDO это не одно и то же?
Ответить | Правка | Наверх | Cообщить модератору

	49. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (49), 12-Фев-26, 20:05
	> В ядре Linux на 12% ускорена обработка входящих UDP-пакетов А в винде внедрен копилот, который за меня решает что и как мне делать в моей (как мне казалось) системе. Недавно перешел на линукс, месяцок привыкания и уже назад не тянет.
	Ответить | Правка | Наверх | Cообщить модератору

2. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–7 +/–
Сообщение от Аноним (2), 12-Фев-26, 16:17
WireGuard станет ещё быстрее! >при проведении стресс-тестирования в 100-гигабитной сети Ой, мимо. В реальном тырнетике не станет.
Ответить | Правка | Наверх | Cообщить модератору

	41. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Bnm (?), 12-Фев-26, 19:35
	Наверно улучшится, если сервер на линуксе будет отдавать сайты быстрее
	Ответить | Правка | Наверх | Cообщить модератору

3. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+13 +/–
Сообщение от kravich (ok), 12-Фев-26, 16:19
Как приятно читать такие новости в наши темные времена десктопного софта на базе веб-технологий и нормализации практики вайбкодинга...
Ответить | Правка | Наверх | Cообщить модератору

	8. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+3 +/–
	Сообщение от Аноним (8), 12-Фев-26, 16:34
	Тебе сейчас напишут, что им ИИшечка такие места сразу пишет правильно... а вот диды...
	Ответить | Правка | Наверх | Cообщить модератору

4. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–2 +/–
Сообщение от Rev (ok), 12-Фев-26, 16:23
То есть до сих пор обработка была ЗАМЕДЛЕНА на 12%? А в Си нет директивы инлайнинга?
Ответить | Правка | Наверх | Cообщить модератору

	6. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+3 +/–
	Сообщение от Совершенно другой аноним (?), 12-Фев-26, 16:33
	> А в Си нет директивы инлайнинга? для соответствующих функций она и была установлена.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–3 +/–
	Сообщение от Аноним (14), 12-Фев-26, 16:45
	Только сейчас. До этого код был замедлен на 12% Возможно программистам-предшественникам было просто класть на производительность.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+6 +/–
	Сообщение от Я (??), 12-Фев-26, 17:05
	Может, у них просто 100Гбит не было?
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (44), 12-Фев-26, 19:43
	Стогигабитные сети в бэкбоне уже дай бог лет десять или около того используются.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (47), 12-Фев-26, 19:58
	https://servernews.ru/1136630
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	23. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+1 +/–
	Сообщение от localhostadmin (ok), 12-Фев-26, 17:11
	> современные протоколы требуют учёта времени поступления пакета Тогда это не имело смысла
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	18. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–5 +/–
	Сообщение от Вася Пупкин (?), 12-Фев-26, 16:53
	почему это нельзя делать везде по умолчанию? как это сделано в расте
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	20. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+5 +/–
	Сообщение от Рулона Боева (?), 12-Фев-26, 17:00
	Потому что инлайнинг функций — это всегда компромисс между экономией инструкций на ее вызов (условно убираем push/call/pop) и итоговым размером объектных файлов, так как тело функции будет дублироваться в каждой функции, которая вызывает встраиваемую.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–1 +/–
	Сообщение от ананим.orig (?), 12-Фев-26, 17:25
	А если в коде будет ошибка, то она размножится соответствующее количество раз. И пока её обнаружат фронт атак тоже увеличится.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от анон (?), 12-Фев-26, 18:11
	> А если в коде будет ошибка, то она размножится соответствующее количество раз. > И пока её обнаружат фронт атак тоже увеличится. Чего-чего? Какой фронт, какое "размножится"? 🤦 Инлайн, это замена "вызов_кода_с_ошибкой" на "копия кода с ошибкай", т.е. что совой о пень, что пнем о сову ...
	Ответить | Правка | Наверх | Cообщить модератору

	26. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Rev (ok), 12-Фев-26, 17:36
	Не понял. Сейчас установлена? Но пишут же, что вручную заинлайнили. Я так это понял, что код функции перенесли туда, где он используется, избавившись от вызова функции.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	28. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Совершенно другой аноним (?), 12-Фев-26, 17:47
	> Не понял. Сейчас установлена? Но пишут же, что вручную заинлайнили. Я так > это понял, что код функции перенесли туда, где он используется, избавившись > от вызова функции. посмотрите patch, ссылка на него есть в тексте новости. Если по-простому, то функции перенесли из файла *.c в файл *.h и дописали static inline.
	Ответить | Правка | Наверх | Cообщить модератору

	29. Скрыто модератором	+1 +/–
	Сообщение от ___ (??), 12-Фев-26, 17:48
	в сетях 100 мбит и процент замедления скорее всего был гораздо меньше, так как частота пакетов была меньше
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	32. Скрыто модератором	+/–
	Сообщение от Аноним (47), 12-Фев-26, 18:03
	https://speed.cloudflare.com
	Ответить | Правка | Наверх | Cообщить модератору

7. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от Аноним (7), 12-Фев-26, 16:34
Жаль только, что тспу очень агрятся на юдп. Но, что-нибудь обязательно будет придумано!
Ответить | Правка | Наверх | Cообщить модератору

	9. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от 12yoexpert (ok), 12-Фев-26, 16:38
	у меня не агрятся, чяднт?
	Ответить | Правка | Наверх | Cообщить модератору

	11. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+1 +/–
	Сообщение от Аноним (7), 12-Фев-26, 16:40
	Повезло с провайдером. Видимо ещё активное оборудование не шибко внедрили.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от 12yoexpert (ok), 12-Фев-26, 16:43
	а модем мой пассивный, по-твоему? и как ты собрался внедрять какое-то оборудование ко мне в мобилку? у меня два провайдера, ни один мне ни о каких внедрениях не сообщал
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (7), 12-Фев-26, 16:47
	Я думал, что там у них есть два класса оборудования и стоит оно до Ваших модемов. Ну да ладно. Главное, что Вам нравится!
	Ответить | Правка | Наверх | Cообщить модератору

	16. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (16), 12-Фев-26, 16:48
	> и как ты собрался внедрять какое-то оборудование ко мне в мобилку? Легко. Одним законом о предустановке российского ПО. Если тспу понадобятся сразу на уровне каждого смартфона.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	19. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от 12yoexpert (ok), 12-Фев-26, 16:55
	какой идиот будет даже заикаться о таком законе, и кому вообще нужны эти ваши тспу? это же цензура. засмеют и выгонят из правительства, если не посадят за шпионаж или измену. да и российское ПО никогда качеством не отличалось. есть хоть какие-то причины делать то, что написано у тебя в комментарии?
	Ответить | Правка | Наверх | Cообщить модератору

	35. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (7), 12-Фев-26, 18:44
	Забористая у Вас! Ну если по теме, есть к примеру множество нужных сервисов, которые спроектированы и хорошо работают именно с дейтаграммами. Котурн например. Но если Вам все нравится, значит Вам наверное это просто неинтересно. Завидую!
	Ответить | Правка | Наверх | Cообщить модератору

	42. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (42), 12-Фев-26, 19:39
	https://www.consultant.ru/legalnews/29310/
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	45. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (47), 12-Фев-26, 19:47
	https://share.google/aimode/vb1x6z1Rkxjx7WZlh
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+1 +/–
	Сообщение от Аноним (25), 12-Фев-26, 17:34
	> что-нибудь обязательно будет придумано! Пройдемте.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	36. Скрыто модератором	+1 +/–
	Сообщение от Аноним (7), 12-Фев-26, 18:46
	Только после Вас:)
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (34), 12-Фев-26, 18:24
	да, хорошая новость, буст в  12% при обработке udp пакетов на тспу это прям приятно! надо потесть, действительно ли есть прироста и если есть, то можно сказать что запилили новую фичу, для работы которой нужно ядро 7.0 и выше, и получить за это премию!
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

10. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от timur.davletshin (ok), 12-Фев-26, 16:39
К пользовательским реализациям никакого отношения не имеет. Там ни разу ничего не упиралось в производительность timecounter_cyc2time().
Ответить | Правка | Наверх | Cообщить модератору

12. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–5 +/–
Сообщение от Аноним (14), 12-Фев-26, 16:41
Миф "о невероятно оптимизированном дидовом коде" развеян. В который раз)) Кто бы мог подумать, что аффторы оригинального кода не знали о возможности инлайна.
Ответить | Правка | Наверх | Cообщить модератору

	17. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+2 +/–
	Сообщение от Аноним (17), 12-Фев-26, 16:52
	а причем тут дидовый код, у вас ведь компиляхтор "луДше" код генерит.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+1 +/–
	Сообщение от Аноним83 (?), 12-Фев-26, 19:07
	Дидам никогда не нужно было знать точное время получения UDP пакета, всё как то без этого прекрасно работало.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	46. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (44), 12-Фев-26, 19:56
	Оно и понятно почему. Все данные умещались на СЕРВЕР-1 с репликацией на СЕРВЕР-2, а оттуда -- на ленту, но только если сегодня робот работает (а не обслуживается вендором). Можно и время не знать, и вручную админить, и даже выучить наизусть оба айпишника (и специально выбрать "красивые", чтобы легче было запоминать). С тех пор многое поменялось, без синхронизации времени и точных временных меток событий современный энтерпрайз не работает.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним83 (?), 12-Фев-26, 20:04
	Всё прекрасно работает, и работало. Не смотрел код NTP клиентов/серверов, но думаю и там разница между временем получения пакета ядром и временем когда приложение его вычитало из сокета не такое значительное. И уж точно не стоял вопрос того что опция сохранения времени ядром частоиспользуемая/заметная на общем фоне, просто никто столько не пулял, даже на тех слабых железках. Для остального был TCP, полностью ядерный, который и вылизывали. И эти самые тайминги там и использовались в CC, хотя тоже вроде не так интенсивно. Ниже я расписал откуда эта дичь вылезла.
	Ответить | Правка | Наверх | Cообщить модератору

21. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от Аноним (21), 12-Фев-26, 17:03
А ещё в linux 6.12.x ip6gre и ip6tnl сломали
Ответить | Правка | Наверх | Cообщить модератору

27. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	–1 +/–
Сообщение от Cyber100 (ok), 12-Фев-26, 17:43
не могу сосчитать без логарифмической линейки и штангенциркуля == если у них на 100гб канале все увеличилось аж на 12%, значит, на 1 гб канале - это будет 1200% или наоборот 0,12%?
Ответить | Правка | Наверх | Cообщить модератору

	30. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+2 +/–
	Сообщение от 12yoexpert (ok), 12-Фев-26, 17:59
	попробуй счёты
	Ответить | Правка | Наверх | Cообщить модератору

31. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от Аноним (31), 12-Фев-26, 18:00
> В данной ситуации автоматические применяемые компилятором оптимизации, такие как FDO (Feedback Directed Optimization), LTO (Link Time Optimization) и PGO (Profile Guided Optimization), не смогли обнаружить горячий сегмент кода и проигнорировали его, А Боромир.. А компилятор Rust'a сам бы всё заинлайинл!
Ответить | Правка | Наверх | Cообщить модератору

	39. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Фамилия (?), 12-Фев-26, 19:15
	То есть, вы хотите сказать, что этот магический компилятор магически видит горячие сегменты кода и магически понимает, что тем людям, которые это дело компилируют надо именно заинлаинить этот кусок кода в угоду производительности на каком-то конкретном тесте? Просто вау. А почему же тогда никто и нигде про эти магические способности не говорит? Это же такая классная реклама! Компилятор, который генерит безопасный код, ещё и знает заранее всё то, что вы и сами ещё пока даже не знаете!
	Ответить | Правка | Наверх | Cообщить модератору

	51. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (51), 12-Фев-26, 20:19
	Ну, справедливости и логики ради, можно придумать и ситуации, когда компилятор и мог бы что-то понять и без магии. Например. Есть функция с передаваемыми параметрами. Небольшая по кол-ву генерируемых команд. И вызывается в программе в трех-четырех местах и два из них - внутри циклов. Почему бы не заинлайнить код не вызывая функцию? Никакой магии, да и наверное даже спец. флажков компилятора, для такого не надо. Вызов небольшой функции внутри цикла - очень вероятный кандидат на горячий сегмент кода.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Фамилия (?), 12-Фев-26, 20:39
	Компилятор да, делает оценки и решает надо ли заинлайнить какую-то функцию или нет (при условии присутствия нужных флагов). Но инлайн-инлайну рознь. Где-то инлайн может дать преимущество, а где-то наоборот. Где-то кэши уместили в себе все заинлаиненные вещи, а где-то не уместили и будет происходить деградация производительности. Компилятор сам по себе не может в общем случае понять, является ли данный сегмент кода горячим. Если бы такое было возможным, то JVM тогда могла бы все горячие функции откомпилировать заранее и стать быстрее Си. Но этого не происходит, а происходит обратное - JVM сначала запускает код и смотрит, а что становится горячим. Что стало, то и оптимизирует. Здесь получилась та же ситуация. Люди запустили и обратили свой взор на конкретное место. Увидев горячее место, провели оптимизацию и получили выигрышь. Это обычный рабочий момент, не надо в нём искать какой-то негатив по отношению того, что авторы используют устаревшие технологии, и что надо просто перейти на новые технологии и всё само станет быстрым и шелковистым. Вот, например: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . Никто с первого раза не написал программу так, чтобы она работала на каком-то классе тестов очень быстро.
	Ответить | Правка | Наверх | Cообщить модератору

37. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
Сообщение от Аноним83 (?), 12-Фев-26, 19:06
> Отмечается, что функция timecounter_cyc2time() может вызываться на каждый входящий пакет, поскольку современные протоколы требуют учёта времени поступления пакета. Кто не понял, поясню: они накостылили http/2 / quick, где им пришлось в юзерспейсе имплементировать cognestion control алгоритмы, для работы которых потребовалось включать опцию для записи времени получения пакета. SO_TIMESTAMP / SO_TS_CLOCK / SO_TIMESTAMPNS. До этого данная опция почти никогда не применялась при работе с UDP ибо нафиг не надо знать время когда пакет пришёл. В худьшем случае в event обработчике чтения в самом начале получали время и считали что все пакеты прочитанные за этот цикл приёма из сокета были получены в это время. Иными словами: 1. Для обычных приложений от этой оптимизации толку 0. 2. Сами себе придумали проблему с quick (юзерспейс TCP) - сами преодолевают.
Ответить | Правка | Наверх | Cообщить модератору

	43. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним (42), 12-Фев-26, 19:42
	UDP это супер полезно. Это аудио и видео звонки.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от Аноним83 (?), 12-Фев-26, 20:05
	Только там временные метки не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема