Re: RT patch acceptance

[john cooper <john.cooper@timesys.com>]

Sven Dietrich wrote:
> Andrew Morton wrote:
> 
>> Daniel Walker <dwalker@mvista.com> wrote:
>>  
>>
>>> I'm not going to ignore any of the discussion, but it would be nice to
>>> hear Andrew's, or Linus's specific objections..
>>>   
>>
>> This thing will be discussed on a patch-by-patch basis.  Contra this 
>> email
>> thread, we won't consider it from an all-or-nothing perspective.
>>
>> (That being said, it's already a mighty task to decrypt your way through
>> the maze-like implementation of spin_lock(), lock_kernel(),
>> smp_processor_id() etc, etc.  I really do wish there was some way we 
>> could
>> clean up/simplify that stuff before getting in and adding more 
>> source-level
>> complexity).
>>
>>  
>>
> The IRQ threads are actually a separate implementation.
> 
> IRQ threads do not depend on mutexes, nor do they depend
> on any of the more opaque general spinlock changes, so this
> stuff SHOULD be separated out, to eliminate the confusion..

There is the assumption a spinlock-mutex can provide
synchronization with interrupt processing.  The means
to effect this is by the interrupt payload running in
task context where it plays by the rules of a spinlock-mutex
(ie: block upon contention).

If the interrupt payload runs in exception context a
blocking spinlock-mutex by definition cannot be used for
synchronization.  Rather we are back to the raw_spinlock
which must also disable exception interrupts in tandem
with acquiring the raw_spinlock -- an attempt to acquire
the raw_spinlock in exception interrupt context must be
guaranteed to always succeed.

So there is a mutual design dependence between IRQ threads
and spinlock-mutexes in order to allow interrupt payload
processing to be pushed into kernel scheduleable task context.
This gives the benefit of minimizing the amount of time a
CPU spends in exception interrupt context and eliminates
the need for the spinlock-mutex to resort to disabling
interrupts in order to synchronize with payload execution.

> There was an original IRQ threads submission by
> John Cooper/ TimeSys, about a year ago, which Ingo
> subsequently rewrote.

I wasn't involved in that work.  The credit there goes to
Scott Wood.

> As a logical prerequisite to the Mutex stuff, the IRQ threads, if broken 
> out,
> could allow folks to test the water in the shallow end of the pool.

Dropping IRQ threads will require either a reversion to
all raw_spinlock usage or creation of a spinlock-mutex
version which disables interrupts for cases where code
must synchronize with exception interrupts.  Neither of
these sounds particularly attractive compared to the
IRQ thread mechanism.

I'd like to hear some technical arguments of why IRQ threads
are held with such suspicion.  Also it isn't the case prior
mechanisms are being obsoleted.   Exception context interrupt
processing and raw_spinlocks to synchronize with them are
still available and will be for those edge cases which
are not addressable via spinlock-mutexes.

-john


-- 
john.cooper@timesys.com