linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: linux-rt-users@vger.kernel.org
Subject: Using patch-2.6.33.7.2-rt30 increases latency and CPU usage?
Date: Wed, 9 May 2012 21:18:10 +0000 (UTC)	[thread overview]
Message-ID: <joemui$6v0$1@dough.gmane.org> (raw)


I've been doing some interrupt latency testing using a board running a
400MHz ARM9 (an Atmel at19sam9g20).  I'm measuring interrupt latency
of an ISR attached to external interrupt pin IRQ0.

I built three kernels from scratch and ran the same test on all three:

 2.6.30          
 2.6.33.7        
 2.6.33.7-rt30  

All kernels are built using the standard AT91 patches from
http://maxim.org.za/at91_26.html.  The 2.6.30 kernel also has a set of
patches distributed by Atmel.

The 2.6.33.7-rt30 kernel is built from the same sources as the 2.6.33.7
kernel with the addition of the 2.6.33.6-rt30 patch.

I don't have enough data to say much about worst-case latency, but
after looking a few thousand samples I can say that...

 * 2.6.30 and 2.6.33.7 are pretty much the same: there is as much
   variation between test runs as there is between kernels.

 * Typical latency with RT patch is 3X the latency without it.

 * CPU idle time during test is 10% with RT patch and 30% without.

IOW: the real-time patch for 2.6.33.7 makes both the typical interrupt
latency and the CPU usage significantly worse.

Typical latency without the RT patch is 5-15us.

Typical latency with is 15-50us (I've never seen latency below 15us
with the RT patch).

Is this the expected behavior?

I don't have enough data to state conclusively what the worst-case
latencies are, but it looks like in all cases they're 200-250us.

In all cases the kernel was configured to be the most preemptible it
could be.  In the 2.6.33.7-rt30 kernel I don't have any of the tracers
enabled.

The kernel configurations are as identical as I could make them.  In
the 2.6.33.7-rt30 case, I started with the .config file used to build
the other 2.6.33.7 kernel and ran old-config making sure to select the
"fully preemptible" option when it asked.

Why would a "vanilla" 2.6.33.7 AT91 kernel perform so much better than
one with the RT patch?

-- 
Grant Edwards               grant.b.edwards        Yow! RHAPSODY in Glue!
                                  at
                               gmail.com


             reply	other threads:[~2012-05-09 21:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09 21:18 Grant Edwards [this message]
2012-05-09 22:00 ` Using patch-2.6.33.7.2-rt30 increases latency and CPU usage? Grant Edwards
2012-05-09 22:13   ` Joachim Achtzehnter
2012-05-09 23:18     ` Grant Edwards
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='joemui$6v0$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).