From: Mark_H_Johnson@raytheon.com
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Amit Shah" <amit.shah@codito.com>,
"Karsten Wiese" <annabellesgarden@yahoo.de>,
"Bill Huey" <bhuey@lnxw.com>, "Adam Heath" <doogie@debian.org>,
emann@mrv.com, "Gunther Persoons" <gunther_persoons@spymac.com>,
"K.R. Foley" <kr@cybsft.com>,
linux-kernel@vger.kernel.org, "Rui Nuno Capela" <rncbc@rncbc.org>,
"Florian Schmidt" <mista.tapas@gmx.net>,
"Fernando Pablo Lopez-Lezcano" <nando@ccrma.stanford.edu>,
"Lee Revell" <rlrevell@joe-job.com>,
"Shane Shrybman" <shrybman@aei.ca>,
"Esben Nielsen" <simlo@phys.au.dk>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Michal Schmidt" <xschmi00@stud.feec.vutbr.cz>
Subject: Re: Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-7
Date: Tue, 30 Nov 2004 08:33:05 -0600 [thread overview]
Message-ID: <OFF4F89D90.B89E0767-ON86256F5C.004C735C@raytheon.com> (raw)
I have results from two builds of -V0.7.31-9. The first
build is CONFIG_RT (RT) and the second is CONFIG_DESKTOP (PK or
as described in .config help - Preempt Kernel).
Both booted OK - so the SMP lockup on _DESKTOP appears to
be fixed. Both ran my test series faster than previous 2.6
kernels. I was seeing run times over 30 minutes before
(mainly due to starvation of non-RT tasks) but both completed
in about 20 minutes.
General notes:
[1] Audio duration was much more variable on the PK than the
RT kernel. The variability on PK audio duration is about 30%
of nominal time. The RT kernel was less variable but tended to
finish well before the nominal time (and you could hear the
difference). The PK results look like buffering inside ALSA
that was not present in OSS?. Not sure why the RT kernel
is almost always finishing too soon.
[2] The PK kernel has much longer latencies as measured by
the in kernel tracing code. The RT kernel basically had NO
latencies > 50 usec where the PK kernel had several over a
millisecond (usually related to disk writes). By this measure
the RT kernel is clearly better.
[3] The overhead of RT (as measured by the CPU loop timing and
by pings from remote systems) is more than the PK kernel. I
believe this is due to the IRQ threading overhead. By these
measures, the PK kernel is better. By elapsed time, the 2.4
kernel is far superior.
More specifics:
The 2.4 numbers are from 2.4.24 w/ low latency / preempt patches.
within 100 usec
CPU loop (%) Elapsed Time (sec) 2.4
Test PK RT PK RT | CPU Elapsed
X 99.69 99.34 90 70 | 97.20 70
top 99.31 98.33 30 31 | 97.48 29
neto 97.28 97.69 205 315 | 96.23 36
neti 97.76 98.11 198 325 | 95.86 41
diskw 69.16* 94.98 51 115 | 77.64 29
diskc 96.44 98.39 230 250 | 84.12 77
diskr 99.60 98.77 240 180 | 90.66 86
total 1044 1286 | 368
* several multiple millisecond latencies measured by the
tracing code. Will send traces separately.
min ave max mdev
PK ping - 0.100 / 0.176 / 1.009 / 0.053
RT ping - 0.194 / 0.322 / 527.635 / 2.263
[not sure why the high max on RT, but I did see a few
1 msec or longer ping responses and many over 400 usec]
--Mark H Johnson
<mailto:Mark_H_Johnson@raytheon.com>
next reply other threads:[~2004-11-30 14:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-30 14:33 Mark_H_Johnson [this message]
2004-12-01 9:02 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2004-12-01 14:57 Mark_H_Johnson
2004-12-01 21:20 ` Ingo Molnar
2004-11-28 19:42 Eran Mann
2004-11-30 8:58 ` Ingo Molnar
2004-11-30 16:20 ` Gene Heskett
2004-11-26 12:12 Rui Nuno Capela
2004-11-29 11:05 ` Ingo Molnar
2004-11-29 11:16 ` Ingo Molnar
2004-11-29 11:24 ` Ingo Molnar
2004-11-29 15:42 ` Ingo Molnar
2004-11-29 13:13 ` Rui Nuno Capela
2004-11-29 14:33 ` Ingo Molnar
2004-11-29 15:23 ` Ingo Molnar
2004-11-30 10:29 ` Rui Nuno Capela
2004-11-30 13:19 ` Ingo Molnar
2004-11-30 15:39 ` Rui Nuno Capela
2004-11-30 16:42 ` Ingo Molnar
2004-12-01 10:32 ` Ingo Molnar
2004-12-01 11:25 ` Ingo Molnar
2004-12-01 12:49 ` Rui Nuno Capela
2004-12-01 12:47 ` Rui Nuno Capela
2004-12-01 15:40 ` Ingo Molnar
2004-12-01 16:06 ` Ingo Molnar
2004-11-30 18:13 ` Remi Colinet
2004-11-30 8:15 ` Ingo Molnar
2004-12-01 8:30 ` Eran Mann
2004-12-01 8:53 ` Ingo Molnar
2004-12-01 18:19 ` Adam Heath
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=OFF4F89D90.B89E0767-ON86256F5C.004C735C@raytheon.com \
--to=mark_h_johnson@raytheon.com \
--cc=amit.shah@codito.com \
--cc=annabellesgarden@yahoo.de \
--cc=bhuey@lnxw.com \
--cc=doogie@debian.org \
--cc=emann@mrv.com \
--cc=gunther_persoons@spymac.com \
--cc=kr@cybsft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mista.tapas@gmx.net \
--cc=nando@ccrma.stanford.edu \
--cc=rlrevell@joe-job.com \
--cc=rncbc@rncbc.org \
--cc=shrybman@aei.ca \
--cc=simlo@phys.au.dk \
--cc=tglx@linutronix.de \
--cc=xschmi00@stud.feec.vutbr.cz \
/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
all inboxes | Powered by JetHome®