Thanks for the answer.
On 9/8/06, Ohad Ben-Cohen <ohadbc@xxxxxxxxx> wrote:
Hi,
> Could anybody please explain me the design philosophies/differences of/between
>Bottom Halves, Softirqs and Tasklets in Linux?.
> I already know that BH weren't designed to exploit SMP architectures,
in the 2.6 world, there is no more BH. it was dumped while the 2.5
kernel was developed. today 'bottom-half' is a general term referring
to all (three)
mechanism the kernel have for deferring work form the interrupt handlers.
the three bottom-halves mechanism the kernel has today are softirqs, tasklets
and work queues.
> I wanted to know their design differences which make them the way they are.
>Why cannot 2 BHs run on different CPUs?...things like that..
softirqs: a statically allocated array of 32 softirq_action entries,
each of which
may represent some work to do. today only 6 are used. two identical
softirqs can
run on two processors concurrently - so you need to use locking for any shared
data. but locking means harming scalability so in this case you most probable
do not need to use softirqs.
in addition, only interrupt handlers can preempt a softirq, so it's a
pretty powerful
form of bottom-halves. that's why it's reserved for the most time
critical systems.
today it is used by the timer, networking, scsi and the tasklets mechanism.
tasklets: based on softirqs, but have a simpler interface, and are easier on the
locking requirements (so most drivers use them). it is designed such that no
two *identical* tasklets can run simultaneously (as opposed to softirqs),
but, two different tasklets *can* run concurrently on two processors,
so there's no global bottleneck.
BH: it is no longer in the kernel, but since you asked i will
generally describe it.
it was a statically created list of 32 entries, each of which represent a job.
since there was no dynamic creation, modules couldn't easily use it.
no two BH could run on the same time on two processors, even if they were
of different types. this made locking issues very easy, but it was a major
drawback on efficiency and scalability.
work queues: the last mechanism. major difference from the two above: runs
in process context, so it can sleep ( e.g. can use semaphores). very easy to use.
based on a kernel thread (there is one for each processor, called events/n).
since it is a simple schedulable entity, simultaneous running can occur, so
if needed you must take care of locking yourself.
cheers,
Ohad.
