From: Grant Edwards <grant.b.edwards@gmail.com>
To: linux-rt-users@vger.kernel.org
Subject: Re: Using patch-2.6.33.7.2-rt30 increases latency and CPU usage?
Date: Wed, 9 May 2012 23:18:07 +0000 (UTC) [thread overview]
Message-ID: <joetve$hm5$1@dough.gmane.org> (raw)
In-Reply-To: 4FAAEBF3.10907@netacquire.com
On 2012-05-09, Joachim Achtzehnter <joachima@netacquire.com> wrote:
> Grant Edwards wrote:
>
>> I've been loaned a clue by somebody on the OSADL mailing list: the RT
>> patches are for improving _user_space_ reponse, and may do so at the
>> expense of both CPU usage and interrupt latency.
>
> The RT patches improve *worst case* latency. They are primarily
> intended for applications that must *always* meet their deadlines,
> not merely most of the time. In return you tend to get increased
> average latency as well as reduced throughput.
Good point.
I eventually figured out that my increased interrupt latency is due to
my ISR being run in a kernel thread instead of as a real ISR. Adding
the IRQF_NODELAY flag gets me the same average latency I had without
the RT patch. [It looks like that flag has a different name in 2.6.39
and later?]
>> As a result, I'm better off without the RT patch if what I care
>> about is interrupt latency.
>
> Yes, if you only care about *typical* interrupt latency but don't
> mind the occasional long delay.
Unfortunately, the requirements are a bit fuzzy -- I've got an ISR
deadline of about 20us that I'm trying to meet [I wouldn't mind a
little chat with the person who designed _that_ requirement into the
hardware]. What I don't know is how hard that deadline is. With the
RT patch (and without IRQF_NODELAY), I miss the deadline most of the
time (I'd guess about 80% of the time).
Without RT or with RT and IRQF_NODELAY, it looks like I meet the
deadline maybe 98% of the time (under test conditions). What I don't
know is if once the deadline is missed it matters weather it's missed
by 50us or by 250us [or if 98% is going to be anywhere close to
acceptible, for that matter].
--
Grant
next prev parent reply other threads:[~2012-05-09 23:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 21:18 Using patch-2.6.33.7.2-rt30 increases latency and CPU usage? Grant Edwards
2012-05-09 22:00 ` Grant Edwards
2012-05-09 22:13 ` Joachim Achtzehnter
2012-05-09 23:18 ` Grant Edwards [this message]
2012-05-10 9:46 ` Remy Bohmer
2012-05-10 13:53 ` Grant Edwards
2012-05-11 13:42 ` Remy Bohmer
2012-05-11 13:56 ` Grant Edwards
2012-05-11 18:46 ` Tim Sander
2012-05-15 17:33 ` Steven Rostedt
2012-05-15 22:58 ` Grant Edwards
2012-05-15 23:06 ` Steven Rostedt
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='joetve$hm5$1@dough.gmane.org' \
--to=grant.b.edwards@gmail.com \
--cc=linux-rt-users@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;
as well as URLs for NNTP newsgroup(s).