Subject: Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
From: Joe deBlaquiere (jadb_AT_redhat.com)
Date: Sun Jan 28 2001 - 18:17:46 EET
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
This archive was generated by hypermail 2b28 : Tue Jan 30 2001 - 17:12:47 EET