Re: Attempted summary of "RT patch acceptance" thread

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Thu, Jun 09, 2005 at 10:59:48PM -0400, Lee Revell wrote:
> On Thu, 2005-06-09 at 16:50 -0700, Paul E. McKenney wrote:
> > On Thu, Jun 09, 2005 at 04:34:11PM -0700, Tim Bird wrote:
> > > Paul E. McKenney wrote:
> > > > Hello!
> > > > 
> > > > Midway through the recent "RT patch acceptance" thread, someone mentioned
> > > > that it might be good to summarize the various approaches.  The following
> > > > is an attempt to do just this, with an eye to providing a reasonable
> > > > framework for future discussion.
> > > > 
> > > > Thoughts?  Errors?  Omissions?
> > > 
> > > I haven't finished it, but it looks great so far.  Are you planning to
> > > repost it to LKML, or otherwise publish it somewhere, after incorporating
> > > feedback?
> > 
> > Glad you like it!
> > 
> > I figured on sending out an update sometime next week, after incorporating
> > feedback.
> 
> I believe you are too friendly to vanilla + CONFIG_PREEMPT.  People are
> still seeing tens or hundreds of ms bumps.

Good point -- I certainly need to add a disclaimer to the effect that
common hardware (such as VGA, last I checked some months ago) can
cause such bumps, as can long-running system calls.  Here is my updated
CONFIG_PREEMPT quality-of-service section:

a.	Quality of service: soft realtime, with timeframe of 100s of
	microseconds for task scheduling and interrupt handling, but
	-only- for very carefully restricted hardware configurations
	that exclude problematic devices and drivers (such as VGA)
	that can cause latency bumps of tens or even hundreds of
	milliseconds (-not- microseconds).  Furthermore, the software
	configuration of such systems must be carefully controlled,
	for example, doing a "kill -1" traverses the entire task list
	with tasklist_lock held (see kill_something_info()), which might
	result in disappointing latencies in systems with very large
	numbers of tasks.  System services providing I/O, networking,
	task creation, and VM manipulation can take much longer.  A very
	small performance penalty is exacted, since spinlocks and RCU
	must suppress preemption.

Does this help, or are there other CONFIG_PREEMPT latency issues that
need to be called out?

> Does the LTP include an RT latency test yet?

Not as far as I know.  I believe that LTP contains primarily pass-fail
rather than performance tests, but regardless of where RT latency
tests live, I believe that there needs to be a good home for them.

There are a number of RT latency tests that people run -- any nominations
for particularly good ones?  Should we be running lmbench at realtime
priority with 15 kernel builds in the background, measuring the
latency of each lmbench operation, in addition to running the existing
scheduler-latency tests?  (Sorry, couldn't resist!)

						Thanx, Paul