Как то вы слишком вольготно, переходите от прерывания сетевой карты к возврату из pselect()/poll()/epoll() (которые происходят через file_operations->poll()).
Они связаны очень опосредованно, более того могут быть не связаны вовсе, как например если используется loopback.
Этот метод эффективнее чем проверка через select или в лоб проверка через recv когда соединений очень много. Не нужно проходить в цикле по всему массиву клиентов.
Программа в user space НИЧЕГО не знает о самих прерываниях в ядре. К тому же при единственном соединении (читай файловом дискрипторе) блокирующий read() по эффективности ничем не отличается от pselect()/poll()/epoll().
Я прям таки думал, что я это объяснил =). Посмотрите пожалуйста разделы "Области применения PCIe NTB" и "Применимость модели QEMU Intel NTB".
Вообще NTB это такой poorman's InfiniBand/RDMA. А конкретно Intel NTB идет в "довесок" к Xeon'ам, есть еще AMD NTB, Renesas и решения от TI из того же семейства.
Perf не справляется с блобом от Nvidia, например, и ещё несколько похожих нюансов.
Как раз интересовал момент, когда ВСЁ хорошо - и с перф и с перфоратор, чтобы сравнить =). Но всё равно спасибо, я думаю и так сам в скором времени сравню.
Так происходит потому, что современные компиляторы по умолчанию не генерируют указатели стековых кадров (frame pointers). Это позволяет сэкономить пару инструкций на функцию и освободить один регистр, однако лишает нас возможности легко профилировать. У Брендана Грега есть отличный обзор проблемы. Популярным решением стало возвращение frame pointers в сборку. В среднем просадка производительности небольшая, около 1–2%. Такой подход часто используют большие компании и дистрибутивы Linux.
А потом
Однако пересобрать все программы и библиотеки с -fno-omit-frame-pointer сложно. Даже если собрать так основной бинарь, всё равно возникнут системные библиотеки, которые собраны с -fomit-frame-pointer. И стеки, которые проходят, например, через glibc, получаются битые. Кроме того, точные цифры замедления сильно зависят от конкретной нагрузки. В некоторых сценариях просадка намного заметнее, вплоть до десятков процентов.
Грег пишет - Ubuntu, Fedora, Arch уже с -fno-omit-frame-pointer тогда возникает вопрос, а что используется, если пересобрать "сложно" ? Если уж мы пошли ловить мух - значит у нас всё должно быть под контролем ? А то мало ли как собрали библиотеки.
А что можете сказать по поводу ORC unwinder в ядре ?
И хотелось бы пример где одно и то же профилировалось с помощью perf, а потом Perforator.
Я пробовал и так и так, честно говоря не подходит mermaid для "больших" диаграмм. Но так удобно их держать в тексте всё таки, уже даже решил сделать конвертер mermaid->dot на ragel.
PPS: при выполнении qemu1 и qemu2 на отдельных ядрах использование binder теряет смысл (тут некому мешаться под ногами)
А оно (использование binder) в принципе не имеет никакого смысла, если вы его привыкли кушать на Android - пожалуйста, но не надо его пытаться подтянуть к любой ситуации.
PPPS: спасибо за кликбейт в названии. Без него прошёл бы мимо и не грокнул (неологизм от Хайнлайн) много нового.
Ну если бы вы прочитали всю статью, а не только заголовок, то проблем бы не было.
Устройство приемное в нем стек реализован некорректно. Такое в quemu вряд ли повторишь. А так получается двойное время тратить. Отладил в эмуляторе и потом по новому в железе
А вот это не факт. В QEMU вполне себе повторишь, может даже оказатся, что в одной ревизии кривой, а в новой уже поправили, такое тоже можно учесть.
Возможно, выгоднее иметь какой-никакой смоук-тест на куче QEMU и небольшое кол-во реальных установок.
Вот только будет ли он эмулирован так же как в железе?
Конечно не будет, модель процесса это не сам процесс.
И не будет ли проще использовать синтезатор (генератор) и МК в железе.
Может будет, а может и не будет. Если у вас всё "под паром", вы владеете хорошо владеете инструментом, то конечно быстрее воспользоваться тем, что есть.
А вот если вы это действие повторяете из раза в раз с тем же самым набором компонентов, тогда чисто "программное" решение, возможно будет выгоднее.
Подключать тот же ST7735 через FT2232H и пробрасывать его в QEMU - боюсь еще тот квест.
Ну как раз USB очень просто пробросить.
Вот как раз на этот вопрос я ищу ответ. С одной стороны, обвешиваться осликами, мультиметрами, логическим анализатором и синтезатором сидя в консоли - муторно. Но будет ли проще в QEMU?
Не зная железа, которое вы используете сложно сказать. Но если брать самый плохой вариант то было бы проще, если бы всё что вам нужно уже было из "коробки". В противном случае это превращается в долгий проект, где вам самому необходимо написать недостающие компоненты.
В QEMU использованном в статье нет и половины всей периферии stm32f103, а в официальном репозитории её еще меньше - но тем не менее того что есть автору для решения своей задачи хватило.
В случае STM32 QEMU это просто программа в userspace не более. Зашумленный сигнал АЦП вы можете смоделировать, в принципе, любой. Остальное тоже можете смоделировать, можете реальное устройство подключить. А нужно ли оно вам это другой вопрос.
Еще раз - unix socket() испольузется только для передачи файловых дескрипторов eventfd(), причем только на старте.
Binder для этих целей, насколько мне известно, использовать можно, но не нужно.
То есть по сути вы заявлете, что запись/чтение eventfd() будет медленее чем какое-то исполнение через Binder. Которое еще необходимо в каком то виде реализовать и предлагаете мне всем этим заняться.
Я, в свою очередь, не вижу каких-либо убедильных доводов в пользу приведенного выше аргумента, которые оправдали бы трату моего времени. Поэтому я предлагаю этим занятся вам - если вы так уверены в своих доводах.
И это не еще вспоминая про ваш заход:
Короче, преимущества конкретного решения перед binder?
Да - всё так.
Вопрос к автору, а вот я ничего не делаю в строке запуска кему для сети и мостов у меня тоже нет, например:
Что я делаю не так =) ?
Ну это же неправда, вообще не нужно знать.
https://wiki.archlinux.org/title/QEMU#User-mode_networking
Актуально, подробно, хорошо!
qemu-system-x86_64 [...] -s -S
gdb vmlinux -ex 'target remote localhost:1234'
kgdb тут вообще нипричём.
Без комментариев - и это человек собирает "минимальное" ядро.
Вместо этого и прочей мути:
git clone --depth=1 -b v5.19.17 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
du --max-depth=1 --block-size=GB
2GB .
qemu-system-x86_64 -cpu host --enable-kvm [...]
Так гораздо веселее.
Как то вы слишком вольготно, переходите от прерывания сетевой карты к возврату из pselect()/poll()/epoll() (которые происходят через file_operations->poll()).
Они связаны очень опосредованно, более того могут быть не связаны вовсе, как например если используется loopback.
Программа в user space НИЧЕГО не знает о самих прерываниях в ядре. К тому же при единственном соединении (читай файловом дискрипторе) блокирующий read() по эффективности ничем не отличается от pselect()/poll()/epoll().
Прерывания ? Что имеется ввиду ?
Я прям таки думал, что я это объяснил =). Посмотрите пожалуйста разделы "Области применения PCIe NTB" и "Применимость модели QEMU Intel NTB".
Вообще NTB это такой poorman's InfiniBand/RDMA. А конкретно Intel NTB идет в "довесок" к Xeon'ам, есть еще AMD NTB, Renesas и решения от TI из того же семейства.
Вторая часть статьи в рамках общей презентации (Функциональная модель PCIe Non-Transparent Bridge в QEMU для P2P обмена данными на практике):
https://habr.com/ru/companies/yadro/articles/877248/
Как раз интересовал момент, когда ВСЁ хорошо - и с перф и с перфоратор, чтобы сравнить =). Но всё равно спасибо, я думаю и так сам в скором времени сравню.
А потом
Грег пишет - Ubuntu, Fedora, Arch уже с
-fno-omit-frame-pointerтогда возникает вопрос, а что используется, если пересобрать "сложно" ? Если уж мы пошли ловить мух - значит у нас всё должно быть под контролем ? А то мало ли как собрали библиотеки.А что можете сказать по поводу ORC unwinder в ядре ?
И хотелось бы пример где одно и то же профилировалось с помощью perf, а потом Perforator.
Спасибо за оценку и комментарий !
Согласен, важно в первую очередь добиться повторяемости эксперимента, иначе не очень понятно, а что мы меряем.
Я пробовал и так и так, честно говоря не подходит mermaid для "больших" диаграмм. Но так удобно их держать в тексте всё таки, уже даже решил сделать конвертер mermaid->dot на ragel.
А оно (использование binder) в принципе не имеет никакого смысла, если вы его привыкли кушать на Android - пожалуйста, но не надо его пытаться подтянуть к любой ситуации.
Ну если бы вы прочитали всю статью, а не только заголовок, то проблем бы не было.
Вы меня окончательно "расстроили", перечитайте вывод пожалуйста (а лучше всю статью еще раз вдумчиво):
И как бы третий столбец с host mitigations=off, недвусмыленно намекает, что дело таки в расходах на переключении контекста.
eventfd() это не POSIX API, а механизм уникальный для Linux.
А вот это большая проблемка, соблюсти времянку тут тяжело будет (если именно прокидывать, а не делать эмуляцию целиком).
С такими вещами всегда готов помочь ! Пишите - буду рад ответить.
Так это каждый для себя сам решает,
Это правда.
А вот это не факт. В QEMU вполне себе повторишь, может даже оказатся, что в одной ревизии кривой, а в новой уже поправили, такое тоже можно учесть.
Возможно, выгоднее иметь какой-никакой смоук-тест на куче QEMU и небольшое кол-во реальных установок.
Так вы сами свой комментарий еще раз прочитайте:
В итоге с изоляцией у меня нет других задач, и переключение только между моей задачей и idle.
Вы правильные вопросы задаёте,
Конечно не будет, модель процесса это не сам процесс.
Может будет, а может и не будет. Если у вас всё "под паром", вы владеете хорошо владеете инструментом, то конечно быстрее воспользоваться тем, что есть.
А вот если вы это действие повторяете из раза в раз с тем же самым набором компонентов, тогда чисто "программное" решение, возможно будет выгоднее.
Ну как раз USB очень просто пробросить.
Не зная железа, которое вы используете сложно сказать. Но если брать самый плохой вариант то было бы проще, если бы всё что вам нужно уже было из "коробки". В противном случае это превращается в долгий проект, где вам самому необходимо написать недостающие компоненты.
В QEMU использованном в статье нет и половины всей периферии stm32f103, а в официальном репозитории её еще меньше - но тем не менее того что есть автору для решения своей задачи хватило.
В случае STM32 QEMU это просто программа в userspace не более. Зашумленный сигнал АЦП вы можете смоделировать, в принципе, любой. Остальное тоже можете смоделировать, можете реальное устройство подключить. А нужно ли оно вам это другой вопрос.
Спасибо за статью!
Не могли бы вы пояснить расхождения использованной версии QEMU с официальной, чтобы всем было понятнее ? Насколько там всё сильно в итоге разошлось ?
Я вижу, что в официальном репозитории реализованы только UART, SPI:
https://elixir.bootlin.com/qemu/v9.2.0-rc3/source/hw/arm/stm32f100_soc.c#L152
Еще раз - unix socket() испольузется только для передачи файловых дескрипторов eventfd(), причем только на старте.
Binder для этих целей, насколько мне известно, использовать можно, но не нужно.
То есть по сути вы заявлете, что запись/чтение eventfd() будет медленее чем какое-то исполнение через Binder. Которое еще необходимо в каком то виде реализовать и предлагаете мне всем этим заняться.
Я, в свою очередь, не вижу каких-либо убедильных доводов в пользу приведенного выше аргумента, которые оправдали бы трату моего времени. Поэтому я предлагаю этим занятся вам - если вы так уверены в своих доводах.
И это не еще вспоминая про ваш заход: