Очереди отложенных действий (work queue)

Сеть + отложенное .* = тормоза

А с чего стало известно, что тормоза в workqueue?

Если бы я знал где конкретно тормоза - я бы не спрашивал :) Буду рад услышать как это можно определить. В u-boot используется поллинг, так вот там этот чип на частоте spi в 10(!) раз меньшей чем в linux имеет скорость при скачивании по tftp в 2(!) раза выше.

не enc28j60 случайно?

Нет, но судя по коду слизан с него. А что - у него такие же проблемы ?

Не знаю. Это я с целью соломки подложить поинтересовался.

Стандартно наверно, использовать профайлер или время/тики печатать.

> там этот чип на частоте spi в 10(!) раз меньшей чем в linux имеет скорость при скачивании по tftp в 2(!) раза выше.

Не думаю, что это можно объяснить исключительно использованием workqueue. Там mdelay где-нибудь не остался? :)

>Стандартно наверно, использовать профайлер или время/тики печатать.

Проблема почти наверняка связана с реализацией порта linux для конкретной железяки, на бигльборде с тем же драйвером и чипом получают результаты на порядок лучше. Пилить то что пилит контора типа embedded alley в тесной связи с производителем около года - мне не представляется перспективным :)

>>Сеть + отложенное .* = тормоза

не факт. Сам видел что после подгрузки драйвера, перехватывающего пакеты через netfilter и отдающего их на обработку в кернельные треды (аналог workqueue), которые просто посылают пакеты обратно в netfilter, пропускная способность гигабитного tcp-соединения увеличивалась 800 до 900 Мб/сек (встроенные в матплату сетевушки). Правда загрузка 4-х ядерного cpu больше :) Тестировал iperf'ом.

>>Какие подситемы ядра вообще используют рабочие очереди ?

большинство используют свои треды:

$ps -Af | fgrep [ | grep d
root 2 0 0 Apr27 ? 00:00:00 [kthreadd]
root 4 2 0 Apr27 ? 00:00:00 [ksoftirqd/0]
root 6 2 0 Apr27 ? 00:00:00 [ksoftirqd/1]
root 232 2 0 Apr27 ? 00:00:00 [bdi-default]
root 234 2 0 Apr27 ? 00:00:00 [kblockd/0]
root 235 2 0 Apr27 ? 00:00:00 [kblockd/1]
root 237 2 0 Apr27 ? 00:00:00 [kacpid]
root 350 2 0 Apr27 ? 00:00:00 [ksuspend_usbd]
root 354 2 0 Apr27 ? 00:00:00 [khubd]
root 357 2 0 Apr27 ? 00:00:00 [kseriod]
root 363 2 0 Apr27 ? 00:00:00 [kmmcd]
root 405 2 0 Apr27 ? 00:00:00 [rpciod/0]
root 406 2 0 Apr27 ? 00:00:00 [rpciod/1]
root 439 2 0 Apr27 ? 00:00:05 [kswapd0]
root 506 2 0 Apr27 ? 00:00:00 [nfsiod]
root 512 2 0 Apr27 ? 00:00:00 [kslowd000]
root 513 2 0 Apr27 ? 00:00:00 [kslowd001]
root 745 2 0 Apr27 ? 00:00:00 [kpsmoused]
root 761 2 0 Apr27 ? 00:00:00 [kstriped]
root 798 2 0 Apr27 ? 00:00:00 [usbhid_resumer]
root 820 2 0 Apr27 ? 00:00:00 [hd-audio0]
root 852 2 0 Apr27 ? 00:00:00 [kjournald]
root 1576 2 0 Apr27 ? 00:00:00 [kjournald]
root 1577 2 0 Apr27 ? 00:00:00 [kjournald]

$ps -Af | fgrep events
root 7 2 0 Apr27 ? 00:00:00 [events/0]
root 8 2 0 Apr27 ? 00:00:00 [events/1]

но для некоторых подсистем заводить отдельный тред слишком жирно - используется default workqueue, ее обслуживает спец. тред(ы) [events]

вот статья:
http://www.linuxjournal.com/article/6916

У меня есть обратный опыт в аналогичной задаче. Может быть там был не «аналог» worqueue, а обработчики гвоздями прибитые к CPU, без шедуллинга и прочей хрени? Тогда - верю :]