linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Date:	Thu, 14 Sep 2006 20:47:10 +0800
From:	"Dong Feng" <middle.fengdong@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Question on The Timer Interrupt Dispatch

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 <middle.fengdong@...il.com>:
> 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/