On Jun 6, 2005, at 11:45 AM, Jonathan Stone wrote:

> That's certainly an internally-consistent strategy, but not at all
> where my interest and focus lies (i.e., networking code). And it
> quantizes improvements at the granuarity of *all* code at a given IPL.
> Whereas the lock-per-IPL lets us proceed as in your patch from 2003.
> The hierarchy of IPL-bound locks lets us do that without flattening
> all device interrupts/IPLs to a single level (which is the part I
> think you described to Stefan as the "hack" part of that patch. ).

So long as you can be interrupted by something that needs to take the  
kernel_lock, you basically need to also run in that perimeter.  So,  
the only way to make incremental progress is to take the "tackle  
highest IPL first" path.

-- thorpej