After submitting the performance/irq fix upstream it turned out the fix should have never worked! I missed a logical "not" in the expression, and did exactly the opposite to what I intended, clearing all the irqs which had not to be cleared, and not clearing the irqs which had to be cleared.
The fact that this wrong code is working means that for some unknown reasons, the interrupts are additionally raised and cleared somewhere else. For the timer it's 99.5% of interrupts: without the improper fix I get ~ 100 spurious interrupt complains per second, with the improper fix it is 1 complain every 2 seconds.
And the fact that the wrong code improves the emulation (NetBSD 1.3.x-1.5.x is working) means there are some counterpart bugs in the code...
Subscribe to:
Post Comments (Atom)
9 comments:
Артём, спасибо за блог. Не могли бы вы пояснить почему ведёте его на английском, а не на родном?
without the improper fix I get ~ 100 spurious interrupt complains pro second
may be
without the improper fix I get ~ 100 spurious interrupt complains per second
Потому что больше читателей. На мой клич "спарководы, отзовитесь" на linux.org.ru откликнулось ровно 0 человек. Плюс, среди русскоязычных нет разработчиков qemu-sparc32. К тому же мало у кого остались 32х битные машинки. Люди, которые тестируют, или обеспечивают мне доступ к железкам - все зарубежом. А уж им-то я просто обязан сообщать о прогрессе, так что без англиского - никак.
Если есть интерес среди русскоговорящих - могу писать и на родном. Но для этого надо чтобы человек 10 набралось. Или хотябы один специалист по спарковскому железу, который предпочитает говорить по-русски. Такие теоретически могут существовать, как минимум среди разработчиков Эльбрус-90, но мне никто не откликнулся.
Производительность даже в user-mode как-то уныло выглядит, вот игрушечный пример:
% grep '^CoreMark 1.0' qemu-* | cut -f 1,4,6 -d ' ' | sort -n -k2
qemu-sparc:CoreMark 230.840259 GCC4.1.1
qemu-m68k:CoreMark 531.349628 GCC4.3.3
qemu-arm:CoreMark 626.744915 GCC4.1.2
qemu-sh4:CoreMark 729.152857 GCC4.3.3
qemu-mipsel:CoreMark 847.522922 GCC4.1.2
qemu-i386:CoreMark 1109.200821 GCC4.1.3
qemu-ppc:CoreMark 1207.000604 GCC4.1.2
celeron-560:CoreMark 7217.847769 GCC4.1.2
Впрочем, в реальной жизни все очень похоже.
А какую версию qemu тестировали? Эмуляция спарка в 0.11 намного быстрее, чем в 0.10. Во всяком случае, по времени загрузки NetBSD.
С моим неправильным патчем, производительность меня вполне устраивает. Загрузка идёт в несколько раз быстрее, чем на реальном железе. Правда, конечно, реальное железо - 10 летней давности...
Стало только хуже:
0.10.6 - 230.84
0.11.0 - 207.06
git - 173.78
Когда здесь не было железных спарков и мипсов, я всерьез задумывался об эмуляции. Тогда прогон всех тестов на qemu-mipsel занимал полчаса, а на qemu-sparc - больше двух. С тех пор число тестов увеличилось, ну а требуемое время возросло где-то на треть.
NetBSD-5.0.1:
qemu-system-sparc-0.10.6 - 489.037411
qemu-system-sparc-git - 341.432820
Для полноты картины осталось откопать linux.
qemu-sparc пока что не годится для замены настоящих машинок. До моего последнего фикса там арифметические операции работали неправильно (они же - операции сравнения, это же risc). Как только допилим до полной совместимости - можно будет браться за производительность, раньше смысла нет, по-моему. Я не могу поручиться, что этот баг в проце был последним: он по всем признакам выглядел как баг в дисковой подсистеме. Кто знает, сколько ещё замаскировалось.
Debian Etch, linux-2.6.18:
qemu-system-sparc-0.10.6 - 664.652568
В user-mode этот же бинарник выдал ~ на 1 больше - т.е. что касается производительности в линуксе, проблема оказалась исключительно в toolchain со speedblue.org. Мда...
Пожалуй, снова имеет смысл поиграться с FATE, сейчас можно сравнить с тем, что получается на железных спарках. Будут интересные результаты - сообщу.
Post a Comment