lots of malloc(M_WAITOK)'s in interrupt context from camisr

[Peter Dufault]

On Tuesday, Apr 29, 2003, at 18:54 US/Eastern, Archie Cobbs wrote:

> John Baldwin wrote:
>> If you need to do more work in your interrupt routine than just 
>> wakeups
>> and dinking with registers, you can always wake up a software 
>> interrupt
>> handler or some other random kthread to do things that take a long 
>> amount
>> of time.
>
> Sure you can do that but I'm saying doing that is more complicated
> than necessary in some situations.
>
>>           Sleeping in an interrupt thread would destroy interrupt 
>> latency
>> far worse than it is now.  I'm sure we can all agree that that would 
>> be
>> unacceptable.
>
> I'm only advocating doing it for rare events like device
> insertion/removal, etc.
>
>>                Rather than making the interrupt thread implementation
>> very complex with magical spawning kthreads and such, I would prefer 
>> that
>> driver authors kick up software interrupt threads and the like on 
>> their
>> own and keep the ithread implementation simple.
>
> I'd argue that complexity in one place is preferable to complexity
> in 100 places (ie., every device driver).
>

The issue is promoting not thinking about what context you're working 
in.
It makes sense to have a clean API for kicking off a worker thread, but 
"automagic"
threads that kick in due to lack of thinking out how things work aren't 
ready for prime time.

To do what you're recommending, use a "Permit me to be naive" flag.
That puts the complexity in one place recognizing that it might not be 
the best place.

Peter

Peter Dufault (dufault at hda.com)