From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Daniel Walker <dwalker@mvista.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Attempted summary of "RT patch acceptance" thread, take 2
Date: Mon, 11 Jul 2005 09:43:22 -0700 [thread overview]
Message-ID: <20050711164322.GD1304@us.ibm.com> (raw)
In-Reply-To: <1121098272.7050.13.camel@c-67-188-6-232.hsd1.ca.comcast.net>
Hello, Daniel,
In principle, one could inspect the Linux kernel with the PREEMPT_RT patch
applied, and calculate the worst-case time during which interrupts are
disabled, though I have not heard of anyone actually doing this. Is this
what you are getting at, or are you thinking in terms of Kristian's and
Karim's testing?
Thanx, Paul
On Mon, Jul 11, 2005 at 09:11:12AM -0700, Daniel Walker wrote:
>
> The PREEMPT_RT description doesn't seem correct. According to your
> "hard" definition, PREEMPT_RT can provably hit a hard deadline for
> interrupt response.
>
> Daniel
>
> On Mon, 2005-07-11 at 07:55 -0700, Paul E. McKenney wrote:
>
>
> >
> > a. Quality of service: "soft realtime", with timeframe of a few 10s
> > of microseconds for task scheduling and interrupt-handler entry.
> > System services providing I/O, networking, task creation, and
> > VM manipulation can take much longer, though some subsystems
> > (e.g., ALSA) have been reworked to obtain good latencies.
> > Since spinlocks are replaced by blocking mutexes, the performance
> > penalty can be significant (up to 40%) for some system calls,
> > but user-mode execution runs at full speed. There is likely to
> > be some performance penalty exacted from RCU, but, with luck,
> > this penalty will be minimal.
> >
> > Kristian Benoit and Karim Yaghmour have run an impressive set of
> > benchmarks comparing CONFIG_PREEMPT_RT with CONFIG_PREEMPT(?) and
> > Ipipe, see the LKML threads starting with:
> >
> > 1. http://marc.theaimsgroup.com/?l=linux-kernel&m=111846495403131&w=2
> > 2. http://marc.theaimsgroup.com/?l=linux-kernel&m=111928813818151&w=2
> > 3. http://marc.theaimsgroup.com/?l=linux-kernel&m=112008491422956&w=2
> > 4. http://marc.theaimsgroup.com/?l=linux-kernel&m=112086443319815&w=2
> >
> > This last run put CONFIG_PREEMPT_RT at about 70 microseconds
> > interrupt-response-time latency. The machine under test was a
> > Dell PowerEdge SC420 with a P4 2.8GHz CPU and 256MB RAM running
> > a UP build of Fedora Core 3.
>
>
>
next prev parent reply other threads:[~2005-07-11 16:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 14:55 Attempted summary of "RT patch acceptance" thread, take 2 Paul E. McKenney
2005-07-11 16:11 ` Daniel Walker
2005-07-11 16:43 ` Paul E. McKenney [this message]
2005-07-11 16:49 ` Daniel Walker
2005-07-11 17:19 ` Paul E. McKenney
2005-07-11 17:25 ` Daniel Walker
2005-07-13 14:29 ` Paul E. McKenney
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=20050711164322.GD1304@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=dwalker@mvista.com \
--cc=linux-kernel@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).