Re: Measuring tools - top and interrupts

[Björn Steinbrink]

On 2006.06.25 07:06:33 +0200, Mike Galbraith wrote:
> On Sat, 2006-06-24 at 21:25 +0200, Björn Steinbrink wrote:
> > On 2006.06.24 18:23:12 +0200, Mike Galbraith wrote:
> > > 
> > > let's see.  Yeah, confirmed.
> > 
> > OK, it also depends on IO APIC being enabled and active, ie. noapic on
> > the kernel command line will fix it as well as disabling
> > CONFIG_X86_IO_APIC. That doesn't help me at all to understand why it
> > happens though.
> 
> Ditto.
> 
> > The only difference with IO APIC disabled seems to be that the irq
> > doesn't get ACKed before update_process_times() gets called.
> > And your "fix" makes it being called outside of the xtime_lock spinlock
> > and with a slightly different stack usage AFAICT.
> 
> (it's still under the xtime lock)

No, with IO-APIC enabled, it's using the local APIC timer, thus
using_apic_timer is 1 and the path right after unlocking in
timer_interrupt() is taken towards update_process_times().

> > But none of these should make a difference, right?
> 
> Not that I can see, but then it's pretty dark down here.  Anybody got a
> flashlight I can borrow? ;-)

Guess I found one, not sure if it works correctly though ;)

Using 4K stacks, we have one stack for hard irqs and one for soft irqs,
both having their own threadinfo and thus preemptcount. Thus the call to
softirq_count() in account_system_time() will always return 0 when
called in hard irq context. Additionally preemptcount is always set to
HARDIRQ_OFFSET in hard irq context, so
hardirq_count() - hardirq_offset is 0 all the time as well.

But that doesn't fit the fact that I at least get hard irq accounting
when booting with noapic. And it also doesn't explain why your fix
works, fixing both, soft and hard irq accounting. Am I missing some
code path that calls smp_local_timer_interrupt? There's
smp_apic_timer_interrupt(), but that seems to be unused on i386.

Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/