Подумалось вдруг...

Если ты про поле count структуры tasklet_struct, то потому, что в него пишут и из него читают в разных местах, абсолютно независимо друг от друга.

Например, enable/disable могут параллельно выполняться. Представь сетевую карту. На одном CPU обработчик прерывания запускает tasklet, на другом в это время выполняется функция закрытия устройства, которая его отключает.

Можно в коде драйвера предусмотреть все возможные случаи, ввести собственные синхронизации, но зачем плодить говно там, где этого можно не делать.

(reordered)

почему они должны быть atomic?

они не должны бы. и есть (был) патч, который переносит
tasklets в workqueue.

проблема (одна из проблем) в том, что

tasklet'ы обрабатываются ksoftirqd

нет. ksoftirqd - это fallback. вообще говоря, tasklets
вызываются прямо из irq path, см irq_exit().

Объясните, что в данном контексте означает атомарность. Я вообще ничего не понял. То, что softirq выполняется на попутном стеке — ясно.

> Я вообще ничего не понял

может, это я не понял...

я имел в виду atomic context, но, возможно, имелось
в виду что-то другое.

>может, это я не понял...

Не, скорей я.

Под atomic context попутный стек понимается?

В общем, ладно. Я понял превратно. TC хочет спросить: «если tasklet'ы обрабатываются ksoftirqd, то почему они должны быть interrupt handler - like? Почему в них не может быть мютексов и прочего говна?»

> TC хочет спросить: «если tasklet'ы обрабатываются ksoftirqd, то почему они должны быть interrupt handler - like?

Да.

Почему в них не может быть мютексов и прочего говна?»

Мютексы не говно, а полезный инструмент :)

>> tasklet'ы обрабатываются ksoftirqd

нет. ksoftirqd - это fallback

А по-моему, это основной механизм. Я тут посмотрел - мои tasklet'ы вызываются через несколько миллисекунд после tasklet_schedule - как-то многовато для irq path.

Вспоминается еще старый трюк с консолями и задиранием приоритета ksoftirqd.

> А по-моему, это основной механизм.

я думаю нет, но это как посмотреть.

насколько я понимаю, исторически bh было сделано
для hardirq, теперь этот механизм обобобщен, есть
tasklets. тут я могу ошибаться, я не видел pre-2.6
ядер, но это не важно.

так или иначе, если hardirq handler взводит softirq_pending,
оно будет выполнено из irq_exit() path (забудем про
in_interrupt() для простоты). в этом случае ksoftirqd
будет задействован только если у нас «переполнение»,
см MAX_SOFTIRQ_RESTART. или если он уже running, но это,
опять-таки, автоматически ловится проверкой in_interrupt().

если же ты делаешь, скажем, tasklet_schedule() в process
context, тогда, разумеется, raise_softirq() полагается
на wakeup_softirqd().

мои tasklet'ы вызываются через несколько миллисекунд

после tasklet_schedule

если ты это делаешь из irq - многовато, согласен. один
из _возможных_ ответов, прерванная задача сделала
local_bh_disable(), тогда «точкой вызова» будет парный
local_bh_enable(), и __do_softirq() будет выполнен в
контексте этой задачи.

вообще, мне кажется что все это порядком устарело. без
особой необходимосьти лучше пользоваться queue_work().

> необходимосьти

да этот пипец какой-то. нельзя как-нибудь отредактировать
свое сообщение?

и так без русских буковок тяжело писать, да еще и дурацкие
описки которые выглядят как систематическая неграмотность.

>если ты это делаешь из irq - многовато, согласен. один из _возможных_ ответов, прерванная задача сделала local_bh_disable(), тогда «точкой вызова» будет парный local_bh_enable(),

Да, из irq. Но никакой магией с bh я не занимаюсь. Кроме того, задержка стабильна, так что я подозреваю планировщик. Надо будет задрать проритет ksoftirqd и посмотреть, что получится.

вообще, мне кажется что все это порядком устарело.

Я тоже :)

без особой необходимости лучше пользоваться queue_work()

Вариант, да.

> Да, из irq.

Кроме того, задержка стабильна

очень странно. ну не может такого быть ;)
у тебя ведь не threaded irq?

даже интересно. я бы попробовал разобраться. для начала,
скажем, тупо напечатать current->pid/comm/preempt_count
перед tasklet_schedule() и из t->func().

>> Кроме того, задержка стабильна

очень странно. ну не может такого быть ;)

ksoftirqd это вполне объяснил бы.

у тебя ведь не threaded irq?

IIRC такое есть только в -rt, а у меня сейчас обычное 2.6.31

для начала, скажем, тупо напечатать current-pid/comm/ preempt_count

В ближайшие дни не смогу :/

> > очень странно. ну не может такого быть ;)

ksoftirqd это вполне объяснил бы.

дык ;)

вопрос только в том, почему это стабильно переносится
в ksoftirqd.