Разработчики SUSE Linux представили (http://www.csn.ul.ie/~mel/blog/index.php?/archives/23-Contin...) проект Marvin (http://www.csn.ul.ie/~mel/results/suse/marvin/), в рамках которого организован процесс непрерывного тестирования производительности ядра Linux. После завершения выполнения очередного набора тестов, Marvin переходит к их повторному выполнению над актуализированными сборками ядра, включающими свежие исправления. Затем результаты сравниваются с прошлым выполнением теста и выявляются регрессивные падения производительности, о которых информируются (http://www.csn.ul.ie/~mel/results/suse/marvin/dashboard-open...) разработчики. Несмотря на то, что система изначально нацелена на тестирование ядра из состава SUSE Enterprise Linux, она также настроена и на тестирование основного ядра Linux.URL: http://www.csn.ul.ie/~mel/blog/index.php?/archives/23-Contin...
Новость: https://www.opennet.ru/opennews/art.shtml?num=42648
Что-то по ссылкам я так и не нашёл информации на каких платформах тестируют. Или один лишь AMD64?
А те регрессии, что накапливались 20 лет определить не получится?
Они уже давно перекрыты повышением в 2^10 раза производительности компов.
Роутеры с вами не согласны
Вы представитель союза (свободных) роутеров? Огласите ваши требования!
> Вы представитель союза (свободных) роутеров? Огласите ваши требования!Это лучше тов. sfstudio спросить, если по существу.
А чего там спрашивать? Всё от задачи зависит.Типовая для роутера это роутинг + NAT. С ним дела обстоят так что после 3.4 версии деградация производительности на одноядерных мипсах порядка 40%, большей частью из-за удаления route cache. В итоге в OpenWRT таки бэкпортнули часть route cache с которой работал контрак это частично решило проблему сократив регресс по скорости где-то до 20%.
В общей сложности сравнивая 2.6.21 и 3.4 (чистые) деградация на mips24kc порядка 30%.
На SMP mips 1004kc так же после 3.4 вплоть до 4.0 наблюдался некоторый завал производительности. С 4.0 стало даже быстрее чем на 3.4 ессно если приюзать XPS/RPS и правильно раскидать прерывания.
Собсно большинство недорогих маршрутизаторов на рынке это именно что-то на mips 24kc.
Но тенденция ясна, всё движется в сторону SMP в итоге оверхид на одноведерных железяках растёт и существенно. Как минимум в части сети, в остальном не тестировал и как бы не особо слежу за остальными подсистемами. Тут пусть другие поделятся.
А появившееся в 3,18 https://www.opennet.ru/opennews/art.shtml?num=41210
>В сетевую подсистему внесены оптимизации, направленные на увеличение производительности пакетной передачи данных. Изменения особенно заметны при обработке большого объёма мелких пакетов. Производительность повышена за счёт организации групповых операций блокировки очереди, а также заполнения/очистки очереди и взаимодействия с драйвером сетевой карты не на уровне отдельных пакетов, а манипулируя порциями пакетов. Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;сказалось положительно на производительности недорогих роутеров?
К сожалению никак не сказалось по сути.BQL требует поддержку на уровне драйверов (у нас она есть), но как бы производительности не добавляет оно динамически крутит размер очереди в драйвере т.е. по сути влияет на задержки т.к. раньше очереди были всегда фиксированными и длинными, полезно в паре с fq_codel.
qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE из того же набора по сути оптимизация блокировок в qdisc. Более того не работает с GSO.
net: Make dev_hard_start_xmit() work fundamentally on lists идея ясна но разницы на одноведерном мипсе с микроскопом не нашёл.
На SMP основной профит в новых ядрах по производительности на транзитной пакетомолотилки получился из-за отказа от root блокировки в контрак что позволило его распараллелить. Плюс ещё стопка патчей на схожую тему.
Однако всё это не компенсирует даже одного единственного удаления route cache. Так что пока мы остановились на 3.4 и мониторим как развивается ситуация проверяя каждую значимую ветку. А пока приходиться самостоятельно бэкпортить достаточно много кода в 3.4 ибо не смотря на то что оно LTS и до сих пор поддерживается, но многие критичные фиксы по сети и оптимизации в него не перененесли, вообще в LTS традиционно сети уделяется очень мало внимания.
>Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;
Тут видимо просто забыли добавить на SMP системах. =) Домашний компутер о 8ми 2ГГц x86 с DDR3 рамой и с огромным кэшем головах это далеко не средний или дешовый роутер с ~400-600МГц одноведерным mips 24kc у которого и L2 то кэша нет вообще никакого и рама дай бог DDR1.
Вендоры специально для таких случаев интегрируют аппаратную обработку NAT в чипы, но нет - будем жевать кактус и использовать чисто программные решения.
А мы и используем PPE и во все поля, но факт остаётся фактом. Да и далеко не для всех кейзов PPE заюзать удаётся.
> В итоге в OpenWRT таки бэкпортнули часть route cacheНебольшой оффтоп по терминологии: не бэкпортнули, а именно портировали. Бэкпорт -- это когда из новых версий в старые переносят.
>> В итоге в OpenWRT таки бэкпортнули часть route cache
> Небольшой оффтоп по терминологии: не бэкпортнули, а именно портировали. Бэкпорт -- это
> когда из новых версий в старые переносят.Ну тут даже не портировали, а привернули/родили/написали лишь отчасти аналогичную логику. Как бы не легче от этого.
Почему нет? Код ядра открыт, архивы доступны - пожалуйста.
Выглядит отвратно html4, на NodeJS им слабо?
Вам шашечки или ехать?
Нам нормальную систему проведения тестов, BuildBot вполне.
нам надо ехать с шашечками
> NodeJSнет, спасибо.