linux-kernel - Re: [Bug #14859] System timer firing too much without cause

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1001251808480.5926@localhost.localdomain>
Date:	Mon, 25 Jan 2010 18:20:38 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Shawn Starr <shawn.starr@...ers.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [Bug #14859] System timer firing too much without cause

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 ?

> 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)

> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/