lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: timer_bh behaviour incorrect for 2.2.13?
On Thu, 9 Dec 1999, Ingo Molnar wrote:

>i believe that is completely unnecessery - remember, if an IRQ happens on
>another CPU, then _that_ CPU will call do_bottom_halves soon. So the only
>thing that has to be ensured: the bh flags manipulated atomically.

Wrong.

CPU0 CPU1
------------- -------------------
hardirq_endlock()
do_IRQ
timer_interrupt()
mark_bh(TIMER_BH)
do_bottom_half
global_bh_count still 1 (other CPU)
so skip bh processing.
iret (return to userspace)
softirq_endlock (too late!)
clear global_bh_count
ret from do_bottom_half
(timer_bh not run) (timer_bh not run)

as just said in UP it only matters that we take irq disabled after we read
active as zero the last time. But in SMP a spinlock is necessary.

When I'll have all the race fixed, I'll think on how to fix the starvation
issue without risking to wait for 10msec (or less than 1msec on alpha)
before processing a bh. I just like hate to left the above SMP races
opened just because they doesn't happen often.

Andrea


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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