[lkml]   [2005]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Attempted summary of "RT patch acceptance" thread
    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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-10 17:55    [W:0.024 / U:35.812 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site