Re: Attempted summary of "RT patch acceptance" thread, take 2

[Daniel Walker <dwalker@mvista.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/