From: pradeep hettiarachchi <pacprnt@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Intel Local APIC behavior on low frequencies
Date: Tue, 22 Sep 2009 12:31:24 -0400 [thread overview]
Message-ID: <8fe204b0909220931j5925938ft5bec2adf19513f5a@mail.gmail.com> (raw)
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.
-Pradeep
next reply other threads:[~2009-09-22 17:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 16:31 pradeep hettiarachchi [this message]
2009-09-22 18:31 ` Arjan van de Ven
-- 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=8fe204b0909220931j5925938ft5bec2adf19513f5a@mail.gmail.com \
--to=pacprnt@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®