I am not sure whether this phenomena is an hardware-specific wired one
or is a result of some design intent. I observed there is fixed delay
since the init thread entered run_init_process() to the secondary CPU
got the first tick, that is, around 7000 tick.
If I add a sleep_on_timeout(), or a busy-loop before the
run_init_process(), the delay period will not change. So I am confused
because that seems something within the ram disk image trigger the
first tick on the secondary CPU.
Could anyone at least confirm whether this is any design intent?
Thanks in advance.
2006/9/13, Dong Feng <[email protected]>:
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]