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

"В ядре 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ообщить модератору

	53. "В ядре Linux на 12% ускорена обработка входящих UDP-пакетов"	+/–
	Сообщение от morphe (?), 12-Фев-26, 20:54
	> Сами себе придумали проблему с quick (юзерспейс TCP) Скорее SCTP, у QUIC есть преимущества над просто TCP для многих задач, как минимум возможность слать датаграммы по тому же каналу (Про URG флаг TCP говорить не надо, пользоваться им тем более, пусть он умрёт вместе с FTP)
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

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

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