Re: Faster timers for Linux 2.1.22

Keith Owens (
Mon, 27 Jan 1997 12:01:00 +1100

On Sun, 26 Jan 1997 14:52:39 +0100 (MET),
Ingo Molnar <> wrote:
>On Sun, 26 Jan 1997, Keith Owens wrote:
>> The aim is to replace cli/sti with disable/enable_bh where possible.
>my problem with disable_bh() is that it doesnt 'buffer' interrupts.
>cli/sti are a bit more expensive (a bit. 16 cycles for cli/sti, not that
>much on a pentium). But when an IRQ happens while being cli-ed, it will go
>off immediately after sti.

Probably a misunderstanding here. The beauty of disable_bh is that it
does not touch IRQ's at all, they can continue to trigger and the top
half routines will be able to run. Bottom halves can also run except
for the single bottom half that is disabled. Instead of locking out
all interrupts, let them run and just disable one section of code.

A lot of kernel code uses cli/sti in what is effectively user driven
code (i.e. in response to a system call) in order to serialise the user
driven code against interrupts. In most of these cases, the cli/sti is
overkill because the data it is accessing is only updated by other user
code (no serialisation required until SMP) or is updated by the bottom
handler. For these cases, disable_bh is better than cli/sti because it
limits the affect of the lock. Of course if you want to access data
that is updated by the top half handler then cli/sti may still be

As for 'buffering', after disable_bh is called, the next interrupt of
any kind including (AFAIK) the timer tick will run any outstanding
bottom half code. This takes precedence over user driven code. It's a
tradeoff, a more local lock and a slightly delayed bh against a global
lock that hits every piece of code.

BTW, there are some fairly long loops inside cli/sti, for example see
ip_msqhst_procinfo in net/ipv4/ip_masq.c.