преимущество тасклета в пользовательском приложении

Question

У меня есть некоторые сомнения с нижней половиной. Вот, я рассматриваю только тасклеты. Кроме того, я рассматриваю только невыгружаемое ядро.

Предположим, рассмотрим драйвер Ethernet, в котором обработка прерываний RX выполняет около 10 вызовов функций. (Плохое программирование :))

Теперь, глядя на перспективу производительности, если в тасклет можно переместить 9 вызовов функций и нужно только 1 вызывать при обработке прерываний, могу ли я действительно добиться хорошей производительности в приложении чтения tcp.

Или, другими словами, когда происходит переключение на приложение пользовательского пространства, будут вызваны все 9 вызовов функций для запланированных тасклетов, в действительности приложение пользовательского пространства сможет получать данные пакета только после "всех пакетов". запланированные "завершены? исправить?

Я понимаю, что, имея нижнюю половину, мы разрешаем все прерывания ... но я сомневаюсь, что приложение, основанное на прерывании, получит что-то, имея все 10 функций в самом обработчике прерываний или в нижней половине.

Короче говоря, с помощью тасклета я могу получить улучшение производительности в приложении пользовательского пространства, здесь?

Answer 1

Поскольку тасклеты не ставятся в очередь, а планируются, то есть несколько аппаратных прерываний, отправляющих один и тот же тасклет, могут привести к вызову одной функции тасклета, вы сможете сэкономить до 90% обработки в крайних случаях ,

С другой стороны, для net-rx уже существует высокоприоритетный программный IRQ.

Answer 2

Тасклет не запускается в контексте пользовательского процесса. Если ваш ISR планирует тасклет, он будет запущен сразу после того, как ваш isr будет сделан, но с включенными прерываниями. Преимущество этого состоит в том, что ваша обработка пакетов не предотвращает дополнительные прерывания.

В вашем примере с TCP аппаратное обеспечение передает пакет сетевому стеку, и ваш драйвер готов - сетевой стек обрабатывает пробуждение процесса и т. Д., Поэтому драйвер hw не может выполнить его в контексте процесса получателя данных, потому что он даже не знает, кто это.

Answer 3

По моему опыту на быстрых машинах перемещение работы с обработчика на тасклет не заставляет машину работать быстрее. Я добавил макросы в обработчик, который может превратить мой вызов schedule_tasklet () в вызов самой функции тасклета, и легко сравнить оба пути и увидеть разницу.

Но важно, чтобы обработчики прерываний заканчивались быстро. Как упомянул Николай, вам может быть полезно, если ваше устройство любит много прерывать, но большинство устройств с высокой пропускной способностью имеют оборудование для устранения прерываний, которое делает эту проблему менее серьезной.

Использование тасклетов - это способ, которым люди с ядром ядра будут что-то делать, поэтому при прочих равных условиях, вероятно, лучше последовать их примеру, особенно если вы когда-нибудь захотите, чтобы ваш драйвер был принят в основное ядро.

Я бы также отметил, что вызов большого количества функций не обязательно является плохой практикой; современные предикторы ветвления могут запускать код с интенсивным ветвлением так же быстро, как и код без ветвлений. Гораздо важнее, на мой взгляд, потенциальные эффекты кэша, связанные с необходимостью выполнять половину работы сейчас, а затем половину работы позже.