Видимо я тебя не понял, ибо мне кажется что вы не просто бьётесь с мельницами, а сначала их шевелите и только потом бьётесь ;)
--
Приличный NIC позволит через MSI генерировать любые 2 прерывания для каждого dma-ring в зависимости от его наполнения (не пуст/заполнен больше половины и т. п.), для local APIC любого приличного процессора (с поддержкой PCI-E). Далее, приличный CPU (либо его серверный мост либо MSI-контроллер) позволит из обработчика прерывания прочитать битовую маску актуальных «взведенных» IRQ. Это примерно оптимальный режим обработки прерываний связкой «приличных» NIC+CPU.
При наличии гипервизора требуется чтобы он понимал «приличное железо» и умел с ним взаимодействовать (настраивать NIC и контроллер MSI) чтобы исключить какую-либо возню с IRQ-масками на пути от железа к гостевой системе. Соответственно https://www.linaro.org/blog/kvm-pciemsi-passthrough-armarm64/ и т.п.
--
Но в нагруженной системе старый-добрый NAPI (с приличными драйверами приличного NIC) должен быть не хуже (если не лучше) всей вышеописанной магии, главное чтобы dma-ring действительно пробрасывался (а не перекладывался) в гостевую систему. И вот тут мне на ум приходят упомянутые ветряные мельницы ;)
Если максимально упрощенно, то ваше решение более-менее правильное. Как минимум не будет шататься туда-сюда, но (скорее всего) будут проблемы со скоростью адаптации и/или оптимальности подбора условного качества.
Если не упрощенно то см "Критерии устойчивости" в wiki-статье (на всякий — там могут быть ошибки, сам не вычитывал).
Мне очевидно что вы в любом случае будите "не видеть моря" (как в упомянутом анекдоте) и называть белое черным.
Поэтому не вижу причин обращать на вас внимания. Адью.
С++ API для libmdbx доступно в ветке c++ на github и скоро (после обкатки и стабилизации) переедет в master. Некоторые ключевые моменты:
приложено много усилий чтобы сделать многочисленные возможности MDBX само-документируемыми и удобными для использования (режимы работы БД, варианты ключей и значений, и т.д.);
от C++11 до C++20 и всего три семантически функциональных класса: среда/БД, транзакция и курсор.
одна библиотека и один заголовочный файл, большую часть которого занимаю классы slice и buffer;
опорное C API также было расширено: (де)регистрация тредов-читателей, предварительное создание экземпляров читающих транзакций и курсоров — в сумме позволяет получить гарантии lock-free для операций чтения.
Самое время посмотреть и высказать пожелания, может чего-то не достает. Code review также приветствуется, но отписывать конечно не сюда, а в телеграм или на github.
Если же говорить про IA32, то основной жупел случился из-за многократного "улучшения и расширения" набора команд с сохранением совместимости. Причем команды изначально были переменной длины, начиная с однобайтовых (что привело к неэффективному и запутанному использованию пространства кодов). Короче, думали не про декодер инструкций, а про совместимость и маркетинг.
Саня, у Штеуда с APIC-ами исторически лучше было. Они это выстрадали, начиная с конца 90x и где-то до середины нулевых. У ARMов в среднем по больнице с этим плохо, но (буквально, скорее всего) если взять не "телефонный" ARM, а "серверный" (т.е. рассчитанный на виртуализацию), то всё будет принципиально лучше.
Тем не менее, если есть зажать на прерывания, то всё равно тормозит (даже с "тремя" VAPIC) в сравнении с DPKD/Netmap/Seastar ;)
Есть старый проверенный прием генерации подобных "писем с обоснованными сомнениями":
Сначала редактора и/или авторам атакуемой статьи пишется письмо с намеренными ошибками и неточностями, в таком стиле чтобы нужный ответ (примерно как отписал Логунов).
Потом пишется атакующая статья, в которой приводятся фрагменты "неподобающего" ответа, но без всей истории переписки, и раздувается наблюдаемый пузырь.
Иногда атакуемого может спасти набитые шишки и/или знание о роде занятий атакующего, но далеко не всегда, ибо атакующие берут в соавторы незасвеченных персон и разыгрывают продуманные многоходовочки. В наблюдаемом случае есть пара "новшеств": формат "открытого письма" и логические обороты с likely.
Но на кону большие деньги, очень большие, и подобные атаки (увы) могут быть организованы даже отдельными менеджерами (крупных корпораций), которые потеряют свои готовые бонусы при невыполнении KPI (а кредит на феррари/недвижимость и т.п. уже был взят...). Соответственно, генерация подобного FUDа все-таки влияет на ситуацию (закупки) и оставляет шансы вписаться в KPI и не потерять условную виллу в Калифорнии.
На всякий: 146% это специально внесенные тестовые данные для проверки (что обрабатывается и перерисовывается при вводе). Причем нереальные значения были выбраны намеренно, чтобы у "прессы" не было соблазна "сфотать и опубликовать явную чушь". Но "независимы СМИ" сделали из этого отдельный "факт", ну а вера "пипла" в "альтернативные источники информации" по-прежнему перевешивает здравый смысл ;D
Эти вакцины на одной платформе, которой занимались ~30 лет.
Поэтому, весьма вероятно, что Российская вакцина от SARS-2 повторит успех вакцины от Эболы, которая остается единственной эффективной и безопасной.
Потому-что авторам "открытого письма" не нужны никакие ответы и тем более протоколы.
Их задача в формулировке очередного "likely" в нужном направлении.
А если-бы цель была иной, то и действовали бы иначе (традиционным способом для науки, а не для политики).
Очередные британские итальянские "эксперты" пишут "открытое письмо" в терминах highly/less likely авторам статьи, чтобы хоть как-то хайпануть, после того как их просто "послали" редактора рецензируемого журнала.
Видимо я тебя не понял, ибо мне кажется что вы не просто бьётесь с мельницами, а сначала их шевелите и только потом бьётесь ;)
--
Приличный NIC позволит через MSI генерировать любые 2 прерывания для каждого dma-ring в зависимости от его наполнения (не пуст/заполнен больше половины и т. п.), для local APIC любого приличного процессора (с поддержкой PCI-E). Далее, приличный CPU (либо его серверный мост либо MSI-контроллер) позволит из обработчика прерывания прочитать битовую маску актуальных «взведенных» IRQ. Это примерно оптимальный режим обработки прерываний связкой «приличных» NIC+CPU.
При наличии гипервизора требуется чтобы он понимал «приличное железо» и умел с ним взаимодействовать (настраивать NIC и контроллер MSI) чтобы исключить какую-либо возню с IRQ-масками на пути от железа к гостевой системе. Соответственно https://www.linaro.org/blog/kvm-pciemsi-passthrough-armarm64/ и т.п.
--
Но в нагруженной системе старый-добрый NAPI (с приличными драйверами приличного NIC) должен быть не хуже (если не лучше) всей вышеописанной магии, главное чтобы dma-ring действительно пробрасывался (а не перекладывался) в гостевую систему. И вот тут мне на ум приходят упомянутые ветряные мельницы ;)
Если максимально упрощенно, то ваше решение более-менее правильное. Как минимум не будет шататься туда-сюда, но (скорее всего) будут проблемы со скоростью адаптации и/или оптимальности подбора условного качества.
Если не упрощенно то см "Критерии устойчивости" в wiki-статье (на всякий — там могут быть ошибки, сам не вычитывал).
Уточняю, Примерно на 99%.
Мне очевидно что вы в любом случае будите "не видеть моря" (как в упомянутом анекдоте) и называть белое черным.
Поэтому не вижу причин обращать на вас внимания. Адью.
…
— Ой, папа, что это было?!
— Море, сынок…
— Где?
Интервью как-раз очень адекватное и "однозначное".
причем решенная неверно
С++API для libmdbx доступно в ветке c++ на github и скоро (после обкатки и стабилизации) переедет в master. Некоторые ключевые моменты:CAPI также было расширено: (де)регистрация тредов-читателей, предварительное создание экземпляров читающих транзакций и курсоров — в сумме позволяет получить гарантии lock-free для операций чтения.Самое время посмотреть и высказать пожелания, может чего-то не достает. Code review также приветствуется, но отписывать конечно не сюда, а в телеграм или на github.
Вы не поняли сарказма ;)
IA64 это на самом деле Итаниум, там VLIW.
Если же говорить про IA32, то основной жупел случился из-за многократного "улучшения и расширения" набора команд с сохранением совместимости. Причем команды изначально были переменной длины, начиная с однобайтовых (что привело к неэффективному и запутанному использованию пространства кодов). Короче, думали не про декодер инструкций, а про совместимость и маркетинг.
Саня, у Штеуда с APIC-ами исторически лучше было. Они это выстрадали, начиная с конца 90x и где-то до середины нулевых. У ARMов в среднем по больнице с этим плохо, но (буквально, скорее всего) если взять не "телефонный" ARM, а "серверный" (т.е. рассчитанный на виртуализацию), то всё будет принципиально лучше.
Тем не менее, если есть зажать на прерывания, то всё равно тормозит (даже с "тремя" VAPIC) в сравнении с DPKD/Netmap/Seastar ;)
Во как дружно минусуют диванные хабро-войска.
Видать все в ЦИК присутствовали и/или ГАЗ Выборы разрабатывали (не выезжая с Украины).
)))
Есть старый проверенный прием генерации подобных "писем с обоснованными сомнениями":
Иногда атакуемого может спасти набитые шишки и/или знание о роде занятий атакующего, но далеко не всегда, ибо атакующие берут в соавторы незасвеченных персон и разыгрывают продуманные многоходовочки. В наблюдаемом случае есть пара "новшеств": формат "открытого письма" и логические обороты с likely.
Но на кону большие деньги, очень большие, и подобные атаки (увы) могут быть организованы даже отдельными менеджерами (крупных корпораций), которые потеряют свои готовые бонусы при невыполнении KPI (а кредит на феррари/недвижимость и т.п. уже был взят...). Соответственно, генерация подобного FUDа все-таки влияет на ситуацию (закупки) и оставляет шансы вписаться в KPI и не потерять условную виллу в Калифорнии.
Там где было нужно и пока было нужно они всё внедряли и внедрили, а обсуждать какие-то желтушные цитаты смысла не вижу.
На всякий: 146% это специально внесенные тестовые данные для проверки (что обрабатывается и перерисовывается при вводе). Причем нереальные значения были выбраны намеренно, чтобы у "прессы" не было соблазна "сфотать и опубликовать явную чушь". Но "независимы СМИ" сделали из этого отдельный "факт", ну а вера "пипла" в "альтернативные источники информации" по-прежнему перевешивает здравый смысл ;D
На всякий — в этом и был сарказм про "СМИ", ибо цитата приведенная предыдущим комментатором семантически сверстана аналогично.
Вот еще хорошая статья по теме в "СМИ" ;)
Эти вакцины на одной платформе, которой занимались ~30 лет.
Поэтому, весьма вероятно, что Российская вакцина от SARS-2 повторит успех вакцины от Эболы, которая остается единственной эффективной и безопасной.
Потому-что авторам "открытого письма" не нужны никакие ответы и тем более протоколы.
Их задача в формулировке очередного "likely" в нужном направлении.
А если-бы цель была иной, то и действовали бы иначе (традиционным способом для науки, а не для политики).
Очередные
британскиеитальянские "эксперты" пишут "открытое письмо" в терминах highly/less likely авторам статьи, чтобы хоть как-то хайпануть, после того как их просто "послали" редактора рецензируемого журнала.