> On Sunday 28 January 2001 17:17, Joe deBlaquiere wrote:
>
>> 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.
>
>
> please, no linux heart pacemaker at sourceforge... :-)
>
>
>> 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).
>
>
> Can't that happen in the 2.4.0 kernel too?
> If interrupts are not disabled during the command queuing any (with more than
> 50 us execution time) interrupt might disturb the setup.
> That part of the code should either:
> a) accept partial success, and continue (can it check current success)
> b) disable interrupts, then shouldn't it use
> spin_lock_irq(...) instead of spin_lock_bh(...)
>
> Where is the code BTW? (file:line)
> is it the functions named do_erase_1_by_16_oneblock?
>
>
that's basically the one, just slightly modified to loop through a list
addresses instead of the single address. It's a negligible performance
gain, but simplified some other code I was testing.
The point is that some small set of operations may need to be atomic and
or executed in a critical time period. Allowing these portions of code
to be preempted opens the door for unexpected failure cases.
A 'perfect' driver would of course still be able to recover (or at least
guarantee it wouldn't crash). Sometimes the timing issues aren't known
or explictly stated, so the driver has 'never failed that way before'
because it hasn't been tested that way.
> What about introducing a timecritical_lock()
> #define timecritical_lock(int maxtime_us) {__cli(); }
> /* local processor only */
>
>
> Any driver using the timecritical_lock are not 100% RTLinux compatible,
> but should be ok in a preemtive kernel where timecritical_locks are
> short compared to "guarantees".
> The parameter maxtime_us is a hint to system integrators - don't use drivers
> with high maxtime in a RT system.
>
> But it will be extremly hart to make any guarantees...
> If the driver needs the PCI bus, it might be locked for burst transfer...
> SMP issues...
>
>
>> Do we
>> push drivers like MTD down into preemptable-Linux? Do we push all
>> drivers down?
>
>
> All drivers should be compatible with preemtive-Linux, they who are not are
> unlikely to be compatible with the current Linux.
>
>
some kind of timecritical_lock() is a possibility. It would seem that
such a construct would coexist with SMP and RTLinux. I guess I'm just a
pessimist in that I expect that having not an explicit lock on time
critical sections will eventually mean that something will invalidate
the timing.
-- Joe- 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/