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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.