lkml.org 
[lkml]   [1997]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Faster timers for Linux 2.1.22
Date
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.



\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.099 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site