From: Andrew Morton <akpm@osdl.org>
To: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org,
rohit.seth@intel.com, asit.k.mallick@intel.com
Subject: Re: [Discuss][i386] Platform SMIs and their interferance with tsc based delay calibration
Date: Fri, 28 Jan 2005 21:17:07 -0800 [thread overview]
Message-ID: <20050128211707.28604d58.akpm@osdl.org> (raw)
In-Reply-To: <20050128185101.A19117@unix-os.sc.intel.com>
Please don't send emails which contain 500-column lines?
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> wrote:
>
> Current tsc based delay_calibration can result in significant errors in
> loops_per_jiffy count when the platform events like SMIs (System Management
> Interrupts that are non-maskable) are present.
This seems like an unsolveable problem.
> Solution:
> The patch below makes the calibration routine aware of asynchronous events
> like SMIs. We increase the delay calibration time and also identify any
> significant errors (greater than 12.5%) in the calibration and notify it
> to user. Like to know your comments on this.
I find calibrate_delay_tsc() quite confusing. Are you sure that the
variable names are correct?
+ tsc_rate_max = (post_end - pre_start) / DELAY_CALIBRATION_TICKS;
+ tsc_rate_min = (pre_end - post_start) / DELAY_CALIBRATION_TICKS;
that looks strange. I'm sure it all makes sense if one understands the
algorithm, but it shouldn't be this hard. Please reissue the patch with
adequate comments which describe what the code is doing.
Shouldn't calibrate_delay_tsc() be __devinit? (That may generate warnings
from reference_discarded.pl, but they're false positives)
>From a maintainability POV it's not good that x86 is no longer using the
generic calibrate_delay() code. Can you rework the code so that all
architectures must implement arch_calibrate_delay(), then provide stubs for
all except x86? After all, other architectures/platforms may have the same
problem.
next prev parent reply other threads:[~2005-01-29 5:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-29 2:51 [Discuss][i386] Platform SMIs and their interferance with tsc based delay calibration Venkatesh Pallipadi
2005-01-29 5:17 ` Andrew Morton [this message]
2005-01-29 6:24 ` Andi Kleen
2005-01-29 17:44 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2005-01-29 14:36 Pallipadi, Venkatesh
2005-01-29 14:37 Pallipadi, Venkatesh
[not found] <3rR0g-3aR-11@gated-at.bofh.it>
2005-01-31 17:25 ` Martin Wilck
[not found] ` <3s4Tx-1gi-9@gated-at.bofh.it>
2005-01-31 17:29 ` Martin Wilck
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=20050128211707.28604d58.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=asit.k.mallick@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rohit.seth@intel.com \
--cc=torvalds@osdl.org \
--cc=venkatesh.pallipadi@intel.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