Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Pavel Machek <pavel@suse.cz>]

Hi!

> > 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.

Nonsense. SMP+SMM BIOS is *very* similar to preemptible kernel.

SMP means that you can run two pieces in kernel at same time. With
preemptible kernel "same" is rather bigger granularity, but thats
minor difference. And SMI BIOS means that cpu can be stopped for
arbitrary time doing its housekeeping. (Going suspend to disk?)

> 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 

With SMM BIOS, this is br0ken.

> 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 

You can dissable SMM interrupts, AFAIK.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/