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.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |