форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Система непрерывного тестирования производительности ядра Linux"	+/–
Сообщение от opennews (ok) on 22-Июл-15, 16:26
Разработчики 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... Новость: http://www.opennet.dev/opennews/art.shtml?num=42648
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Система непрерывного тестирования производительности ядра Li..."	+1 +/–
Сообщение от A.Stahl (ok) on 22-Июл-15, 16:26
Что-то по ссылкам я так и не нашёл информации на каких платформах тестируют. Или один лишь AMD64?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Система непрерывного тестирования производительности ядра Li..."	–1 +/–
Сообщение от Аноним (??) on 22-Июл-15, 17:03
А те регрессии, что накапливались 20 лет определить не получится?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Система непрерывного тестирования производительности ядра Li..."	–7 +/–
	Сообщение от rshadow (ok) on 22-Июл-15, 17:11
	Они уже давно перекрыты повышением в 2^10 раза производительности компов.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Система непрерывного тестирования производительности ядра Li..."	+12 +/–
	Сообщение от Аноним (??) on 22-Июл-15, 17:37
	Роутеры с вами не согласны
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Июл-15, 18:19
	Вы представитель союза (свободных) роутеров? Огласите ваши требования!
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Система непрерывного тестирования производительности ядра Li..."	+5 +/–
	Сообщение от Michael Shigorin (ok) on 22-Июл-15, 18:34
	> Вы представитель союза (свободных) роутеров? Огласите ваши требования! Это лучше тов. sfstudio спросить, если по существу.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "Система непрерывного тестирования производительности ядра Li..."	+12 +/–
	Сообщение от sfstudio (ok) on 22-Июл-15, 21:46
	А чего там спрашивать? Всё от задачи зависит. Типовая для роутера это роутинг + 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 в итоге оверхид на одноведерных железяках растёт и существенно. Как минимум в части сети, в остальном не тестировал и как бы не особо слежу за остальными подсистемами. Тут пусть другие поделятся.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	12. "Система непрерывного тестирования производительности ядра Li..."	+1 +/–
	Сообщение от Аноним (??) on 22-Июл-15, 23:33
	А появившееся в 3,18 http://www.opennet.dev/opennews/art.shtml?num=41210 >В сетевую подсистему внесены оптимизации, направленные на увеличение производительности пакетной передачи данных. Изменения особенно заметны при обработке большого объёма мелких пакетов. Производительность повышена за счёт организации групповых операций блокировки очереди, а также заполнения/очистки очереди и взаимодействия с драйвером сетевой карты не на уровне отдельных пакетов, а манипулируя порциями пакетов. Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера; сказалось положительно на производительности недорогих роутеров?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Система непрерывного тестирования производительности ядра Li..."	+7 +/–
	Сообщение от sfstudio (ok) on 22-Июл-15, 23:55
	К сожалению никак не сказалось по сути. 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.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	17. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от 1283648282 on 23-Июл-15, 12:01
	Вендоры специально для таких случаев интегрируют аппаратную обработку NAT в чипы, но нет - будем жевать кактус и использовать чисто программные решения.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "Система непрерывного тестирования производительности ядра Li..."	+1 +/–
	Сообщение от sfstudio (ok) on 23-Июл-15, 12:12
	А мы и используем PPE и во все поля, но факт остаётся фактом. Да и далеко не для всех кейзов PPE заюзать удаётся.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от freehck (ok) on 11-Авг-15, 15:57
	> В итоге в OpenWRT таки бэкпортнули часть route cache Небольшой оффтоп по терминологии: не бэкпортнули, а именно портировали. Бэкпорт -- это когда из новых версий в старые переносят.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	20. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от sfstudio (ok) on 11-Авг-15, 16:04
	>> В итоге в OpenWRT таки бэкпортнули часть route cache > Небольшой оффтоп по терминологии: не бэкпортнули, а именно портировали. Бэкпорт -- это > когда из новых версий в старые переносят. Ну тут даже не портировали, а привернули/родили/написали лишь отчасти аналогичную логику. Как бы не легче от этого.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	15. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от CSRedRat (ok) on 23-Июл-15, 08:55
	Почему нет? Код ядра открыт, архивы доступны - пожалуйста.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Система непрерывного тестирования производительности ядра Li..."	–9 +/–
Сообщение от Аноним (??) on 22-Июл-15, 18:32
Выглядит отвратно html4, на NodeJS им слабо?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Июл-15, 19:06
	Вам шашечки или ехать?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	10. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Июл-15, 19:10
	Нам нормальную систему проведения тестов, BuildBot вполне.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Система непрерывного тестирования производительности ядра Li..."	–1 +/–
	Сообщение от iPony on 23-Июл-15, 10:00
	нам надо ехать с шашечками
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	13. "Система непрерывного тестирования производительности ядра Li..."	+/–
	Сообщение от Аноним (??) on 22-Июл-15, 23:39
	> NodeJS нет, спасибо.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

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

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