Re: [PATCH] i386: Fix softirq accounting with 4K stacks

On 2006.06.25 19:43:17 +0200, Arjan van de Ven wrote:
On Sun, 2006-06-25 at 19:44 +0200, Mike Galbraith wrote:
On Sun, 2006-06-25 at 16:24 +0200, Björn Steinbrink wrote:

Still no idea why your "fix" works, but the following patch also fixes
the problem and is at least a little more like the RightThing.

Yeah. I don't know about you, but I fully intend to blatantly ignore
that 'why' ;-)

the why is relatively easy ;)

since the "is a softirq executing" bit is on the stack, and each context
(user, soft and hard irq) has their own stack, it's not automatic that
the hardirq stack gets the softirq-executing flag... which your patch
fixes.

That's mine, not Mike's. Mike's patch removed the #ifdef CONFIG_SMP
around update_process_times() in smp_local_timer_interrupt().

NMI's and apic irqs generally don't go via the normal irq path and thus
don't do a stack switch... so they don't lose the bit (for accounting
purposes)

Hm, doesn't that mean that mean that hardirq accounting is still broken?
APIC irq comes in, increases hardirq count, then the timer irq fires,
switches the stack and looses the hardirq count that was incremented by
the APIC irq.

I just booted with both patches applied, mine and Mike's, and that
actually makes a difference in hardirq cpu time accounting. With my
patch only, hi is 0 in top while the box gets a ping flood. With both
patches, I get about 1% hi. Mike's patch causes update_process_times()
to be called twice on UP, but that alone shouldn't change the
percentages, right?
OTOH top shows "hi" as zero with 8K stacks as well unless Mike's patch
is applied, so the results with Mike's patch are bogus (if so, why?) or
hardirq accounting is broken in general.

Btw, which path do apic irqs go? I stumbled across the nmi stuff, but
didn't see anything special for the apic irqs.

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/

Relevant Pages

  • Re: Wine and mmap
    ... Apply the attached patch for vm_mmap to ... > compile and install wine. ... This seems to just work around a side effect of the kernel mmap patch. ... * top of the main stack. ...
    (freebsd-current)
  • Re: RFC: TSO patch for current
    ... > This is a patch for the stack and the em driver to enable TSO ...
    (freebsd-current)
  • Re: RFC: TSO patch for current
    ... > This is a patch for the stack and the em driver to enable TSO ...
    (freebsd-net)
  • Re: [PATCH] m68knommu: add pretty back strace
    ... The backtrace shows resolved function names and their numeric ... This is really not my area, but this patch reminds me of all the dwarf2 unwinder on x86 that caused so many problems in the beginning... ... The old method printed every value from stack which was in the text ... find a pattern without frame pointers but I had no luck. ...
    (Linux-Kernel)