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/
