linux-kernel - Question on The Timer Interrupt Dispatch

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-next>] [day] [month] [year] [list]

Message-ID: <a2ebde260609130826u12a82ffy2c71dd5ec7c4f6bd@mail.gmail.com>
Date:	Wed, 13 Sep 2006 23:26:50 +0800
From:	"Dong Feng" <middle.fengdong@...il.com>
To:	"Andi Kleen" <ak@...e.de>, liqiang@...tel.com,
	"李强" <victor.liqiang@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Question on The Timer Interrupt Dispatch

One question confuses me for quiet a while about the initialization of
the IO APIC.

For my understanding, in i386 architecture, the timer interrupts are
dispatched among every CPU in a roughly round-robin fashion
*immediately* (or reasonably short) after the IO APIC has been
initialized and a secondary CPU has enabled its local IRQ. Turning to
code, I suppose the first condition should be met by [init() ->
smp_prepare_cpus() -> smp_boot_cpus() -> smpboot_setup_io_apic() ->
setup_IO_APIC()], and the second condition should be met by [
start_secondary() -> local_irq_enable() ].

I tried to confirm my guess by tracing the initialization code
execution on my Dual-core laptop . However, I get very confusing
result. While both the conditions had just been met as described
above, CPU 0 has handled about 70 ticks (i.e. timer interrupt) and CPU
1 has handled 0 tick. I expected CPU 1 would get its first timer
interrupt after few ticks. But the fact is that CPU 1 has not been
interrupted by timer until CPU 0 has handled over 7000 ticks. Since
CPU 1 gets the first interrupt, the subsequent timer interrupts are
distributed on both CPU roughly equally.

I still can not find any explanation myself for the gap between my
presumption and the result from code tracing. According to the
presumption, CPU 1 should get the first interrupt while CPU 0 handles
70 ticks, but CPU 1 does not until CPU 0 handles over 7000 ticks.
Could you please pointed out which part I missed in my understanding?

Thanks.
-
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/