From: Arjan van de Ven <arjan@infradead.org>
To: pradeep hettiarachchi <pacprnt@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Intel Local APIC behavior on low frequencies
Date: Tue, 22 Sep 2009 20:31:44 +0200 [thread overview]
Message-ID: <20090922203144.5f3694d6@infradead.org> (raw)
In-Reply-To: <8fe204b0909220931j5925938ft5bec2adf19513f5a@mail.gmail.com>
On Tue, 22 Sep 2009 12:31:24 -0400
pradeep hettiarachchi <pacprnt@gmail.com> wrote:
> Hi,
>
> Here’s a description of my problem. It would be great if you can find
> some info on this matter.
>
>
>
> I need to find some information about local APIC and CPU frequency
> scaling behavior. Currently I am modifying the Linux kernel for my
> research, which involves studying a custom job scheduler I am
> developing at different CPU frequencies. As we know, if the kernel
> works in tick-less mode (and in hi resolution mode) it uses the local
> APIC as a clock event device and as the clock tick device.
>
>
>
> My working environment is: Linux vanilla kernel 2.6.24, Intel core 2
> Quad Q6600, Intel core 2 duo T6500 processors. Gcc compiler and the
> tool chain.
>
> The information I am trying to find is:
>
> 1) I want to find-out the tick count(say for a 100 ms period) of the
> local APIC when the CPU operates at different operating frequencies.
> When I study this matter, I found that the local APIC does not tick
> (does not work accurately) reliably as the clock frequency is varied.
> It works accurately in the maximum frequency of the system. Do you
> know any reason for that? or it is the way it operates?(is that
> normal?)
>
> (my observation: when I count the LAPIC tick count for the maximum CPU
> frequency, it matches with the number of ticks that the system
> generates at the time of the initial LAPIC calibration, which happens
> at the very beginning of the kernel initialization; however when I try
> to count the number of ticks with scaled frequencies, the LAPIC
> "current counter" difference is very less, some times less than 100
> for 100 ms, which should not be true.)
>
> I don't have good reason to think that, some other task re-programs
> the LAPIC: I set the LAPIC "initial counter" to a huge value, further
> I assume when the system works in hi resolution mode, the re-program
> happens from the LAPIC handler "hrtimer_interrupt" which I replace
> with a dummy handler.
>
> Thank you in advance.
the local apic timer is not impacted by the cpu frequency. HOWEVER,
it will stop when the CPU is idle.
next prev parent reply other threads:[~2009-09-22 18:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 16:31 pradeep hettiarachchi
2009-09-22 18:31 ` Arjan van de Ven [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-09-22 16:30 pradeep hettiarachchi
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=20090922203144.5f3694d6@infradead.org \
--to=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pacprnt@gmail.com \
/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®