Messages in this thread | | | Date | Fri, 11 Apr 2003 11:27:28 +0200 | From | Ingo Oeser <> | Subject | Re: 2.4.20 kernel/timer.c may incorrectly reenable interrupts |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |