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. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
