From: Thomas Gleixner <tglx@linutronix.de>
To: "M. Koehrer" <mathias_koehrer@arcor.de>
Cc: lclaudio@uudg.org, linux-rt-users@vger.kernel.org
Subject: Re: Disabling lapic timer for a certain core
Date: Fri, 5 Mar 2010 08:05:01 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.1003050659380.2014@localhost.localdomain> (raw)
In-Reply-To: <6756648.1267736627501.JavaMail.ngmail@webmail08.arcor-online.net>
On Thu, 4 Mar 2010, M. Koehrer wrote:
> Hi Luis,
Please do _NOT_ top post. Please reply inline and in context.
> thanks for the reply.
> It is an Intel Core2Quad CPU - one CPU with 4 cores,
> this is a SMP system...
> Concerning the SMI issue:
> I have globally disabled SMI with the LPC registers...
I hope you know what you are doing. Disabling SMIs can be dangerous in
various aspects:
- thermal protection might be disabled by it
- SMIs which fix chip(set) erratas are not longer working
You should at least confirm with your hardware vendor whether it's
safe to do so and which side effects you have to take into account.
> The main board is a server board from Supermicro,
> no USB enabled, VGA text mode only. No X running.
>
> The total amount of time we have for a cycle is 40us,
FYI, 40us is in the range where the hardware induced latencies can
bite you already badly. You run on a machine with shared L2 caches, so
your other core(s) might evict your code / data and you run into cache
misses which might take a while due to DMAs running etc...
These machines are designed for throughput, not for deterministic
behaviour in the single digit micro seconds range.
> The issue is here, that the interrupt routine of the kernel
> takes too long here.
> It would be fine to have the timer interrupt called more
> often and to process with each call only a subset of the
> jobs to be done...
> This would reduce the time the CPU the user mode
> is interrupted by the timer routine.
Err, by splitting the work you introduce even more overhead. That's
the wrong approach. The first question is which timers are running on
that CPU as you have isolated it.
/proc/timer_stats and /proc/timer_list and the event tracer might help
you to identify them.
In theory it's possible to remove the timer interrupt from such an
isolated core completely, but there needs to be some work done vs. the
scheduler, accounting, RCU etc. There are people looking into this,
but we have no patches yet.
> The idea of running this application in an endless loop is to avoid
> to use timers (including the interrupt latency caused by them).
> By pure polling, no interrupt is required.
What kind of application is that ? Data acquistion or closed loop
processsing ?
Thanks,
tglx
next prev parent reply other threads:[~2010-03-05 7:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 21:03 Re: Disabling lapic timer for a certain core M. Koehrer
2010-03-05 7:05 ` Thomas Gleixner [this message]
2010-03-05 13:54 ` M. Koehrer
2010-03-06 9:18 ` Thomas Gleixner
-- strict thread matches above, loose matches on Subject: below --
2011-05-23 21:40 Joe Howard
2011-05-23 23:49 ` Frank Rowand
2010-03-04 12:29 M. Koehrer
2010-03-04 14:04 ` Luis Claudio R. Goncalves
2010-03-05 9:59 ` Mark Hounschell
2010-03-05 10:31 ` Jan Kiszka
2010-03-06 9:10 ` Thomas Gleixner
2010-03-06 13:12 ` Mark Hounschell
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=alpine.LFD.2.00.1003050659380.2014@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=lclaudio@uudg.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mathias_koehrer@arcor.de \
/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