Messages in this thread |  | | From | Keith Owens <> | Subject | Re: Faster timers for Linux 2.1.22 | Date | Mon, 27 Jan 1997 12:01:00 +1100 |
| |
On Sun, 26 Jan 1997 14:52:39 +0100 (MET), Ingo Molnar <mingo@pc5829.hil.siemens.at> 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 required.
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.
|  |