On Monday 25 January 2010 12:20:38 Thomas Gleixner wrote: > On Mon, 25 Jan 2010, Shawn Starr wrote: > > On Monday 25 January 2010 05:35:50 Thomas Gleixner wrote: > > > Shawn, why can't you use dynamic ticks ? In the bugzilla I just see > > > that you worry about the IRQ0 interrupts (which are correct and > > > necessary when the system is in nohz mode) and the extra rescheduling > > > interrupts. How is the system misbehaving ? > > > > Well, this all stems from trying to use Radeon KMS with IRQs > > on. Doing so I see system stalls and this is quite noticeable > > however, I am able to show this same stall on the quad core with the > > x> same GPU. Right now, it is unclear to me if there is a underlying > > > irq issue or a bug in the radeon driver code that is showing these > > stalls. Since the radeon folks - at the moment - do not think it is > > a coding problem in their driver > > Does the stall go away, when you disable dynticks ? > It does not, no. > > My impression was using dynamic ticks meant ticks were on demand and > > Dynamic ticks are providing a continuous tick long as the machine is > busy. When a core becomes idle, we programm the timer to go off at the > next scheduled timer event, if the event is longer away than the next > tick. When the core goes out of idle (due to the timer or some other > event) we restart the tick. > > So you see less timer interrupts (IRQ0 + Local timer interrupts) With dynamic ticks on or off, LOC increments rapidly, but I assume that is normal behavour. So if none of this really is a kernel issue, I defer it to the radeon folks to comment further. Please remove from regression list, I'll close the original bug. > > > not continuous. On the quad core box, with dynamic ticks on, the > > broadcasts are not increasing IRQ 0 events this only happens on the > > laptop. > > Right, that is expected as I explained already. Your desktop does not > use deeper power states. Check /proc/acpi/processor/CPU0/power on both > machines to see the difference. You _cannot_ compare a desktop and a > laptop machine and deduce a regression. > > The broadcast mechanism is necessary because the local APIC timer > stops in deeper power states. That's a hardware problem. So if the > core goes into a deeper power state then we arm the broadcast timer > which fires on IRQ0 to wake us up. It is a single timer which is used > by all cores in a system to work around this hardware stupidity. It's > named broadcast because it broadcasts the event to the other cores > when necessary. Your desktop does not use deeper power states, > therefor it does not use the broadcast timer either. > > So the timer IRQ0 increasing is neither a Linux BUG nor a regression. > > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
