Re: 2.4.20 kernel/timer.c may incorrectly reenable interrupts

[Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>]

On Fri, Apr 11, 2003 at 12:15:54AM -0700, george anzinger wrote:
> As machines get faster and faster, it will be come more and more of a 
> burden to "stop the world" and sync with the interrupt system, which 
> is running at a much slower speed.  This is what the cli / sti/ 
> restore flags causes.  I saw one test where the time to do the cli was 
> as long as the run_timer_list code, for example.

Maybe we could replace some cli/sti pairs with spinlocks? If it
takes more time to cli/sti than to run the whole code section
that will be protected by the spinlock, then it might be better
to use that instead and block in the IRQ dispatch code.

But I have no measures, how fast the spinlocks are in the
non-/contention case

Problems: 
   - The total amount of CLI/STI doesn't matter, for spinlocks it
     does (they are not recursive)

   - spinlocks are usally not compiled in

   - Older CPUs may still benefit from cli/sti.

What do you think?

Regards

Ingo Oeser
-- 
Marketing ist die Kunst, Leuten Sachen zu verkaufen, die sie
nicht brauchen, mit Geld, was sie nicht haben, um Leute zu
beeindrucken, die sie nicht moegen.