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]
| |
 |