mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dong Feng" <middle.fengdong@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Question on The Timer Interrupt Dispatch
Date: Thu, 14 Sep 2006 20:47:10 +0800	[thread overview]
Message-ID: <a2ebde260609140547xff48956rcf610f208500b7d5@mail.gmail.com> (raw)
In-Reply-To: <a2ebde260609130826u12a82ffy2c71dd5ec7c4f6bd@mail.gmail.com>

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@gmail.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.
>

      reply	other threads:[~2006-09-14 12:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-13 15:26 Dong Feng
2006-09-14 12:47 ` Dong Feng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2ebde260609140547xff48956rcf610f208500b7d5@mail.gmail.com \
    --to=middle.fengdong@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®