[lkml]   [2001]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-audio-dev] low-latency scheduling patch for 2.4.0
    Andrew Morton wrote:

    > There has been surprisingly little discussion here about the
    > desirability of a preemptible kernel.

    And I think that is a very intersting topic... (certainly more
    interesting than hotmail's firewalling policy ;o)

    Alright, so suppose I dream up an application which I think really
    really needs preemption (linux heart pacemaker project? ;o) I'm just not
    convinced that linux would ever be the correct codebase to start with.
    The fundamental design of every driver in the system presumes that there
    is no preemption.

    A recent example I came across is in the MTD code which invokes the
    erase algorithm for CFI memory. This algorithm spews a command sequence
    to the flash chips followed by a list of sectors to erase. Following
    each sector adress, the chip will wait for 50usec for another address,
    after which timeout it begins the erase cycle. With a RTLinux-style
    approach the driver is eventually going to fail to issue the command in
    time. There isn't any logic to detect and correct the preemption case,
    so it just gets confused and thinks the erase failed. Ergo, RTLinux and
    MTD are mutually exclusive. (I should probably note that I do not intend
    this as an indictment of RTLinux or MTD, but just an example of why
    preemption breaks the Linux driver model).

    So what is the solution in the preemption case? Should we re-write every
    driver to handle the preemption? Do we need a cli_yes_i_mean_it() for
    the cases where disabling interrupts is _absolutely_ required? Do we
    push drivers like MTD down into preemptable-Linux? Do we push all
    drivers down?
    In the meantime, fixing the few places where the kernel spends an
    extended period of time performing a task makes sense to me. If you're
    going to be busy for a while it is 'courteous' to allow the scheduler a
    chance to give some time to other threads. Of course it's hard to know
    when to draw the line.

    So now I am starting to wonder about what needs to be profiled. Is there
    a mechanism in place now to measure the time spent with interrupts off,
    for instance? I know this has to have been quantified to some extent, right?

    Joe deBlaquiere
    Red Hat, Inc.
    307 Wynn Drive
    Huntsville AL, 35805
    voice : (256)-704-9200
    fax : (256)-837-3839

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:24    [W:0.023 / U:20.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site